Re: Documentation tools
2010/9/9 Mark Engelberg : > On Wed, Sep 8, 2010 at 11:56 PM, Laurent PETIT > wrote: >>> Full ack here. >> >> For the non english speaker I am : is this a pun/playword ? (full ack >> <-> f..ck all) ? > > I assume he meant "full acknowledgment" -- an expression of agreement. Yes, but since Phil intends to be "bad and nation wide" :-p -- 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: can't def m-bind because namespace
Not really, but monad can be a bit tricky at first. Your first email was a namespace related problem, that has little to do with monads. But it can be better to start with other part of clojure and come back to monads later. They can be useful to refactor code or write a nicer program, but you can always do without them. Best. Nicolas. On Wed, Sep 8, 2010 at 2:27 PM, MohanR wrote: > So actually it looks like I need to understand type theory to > understand this. > > > Thanks, > Mohan > > On Sep 7, 7:04 pm, Nicolas Oury wrote: >> > ...and report your findings here or blog somewhere if you don't mind >> > :) I've been reading a lot about monads lately and can't get my head >> > around it yet so any help appreciated (I'm coming from Java and >> > Clojure is my first real functional language - that's why it causes >> > headaches, I believe). >> >> I have no blog so I will try an explanation here. >> I think monad are quite difficult to grasp, so the more different >> explanations you read, the better. >> Monads are made to represent computations in an abstract way. >> Sometimes the basic computation laws are not those you want >> and then you want to introduce other computation laws. >> Monad is one way to do so (among other like applicative functors or >> Kieisli arrows) >> Monad corresponds to the computations that are best described as an >> imperative program. >> >> So a monad is a type transformer: M for all A , in Java words. >> Something of type M is a computation in the world of computation M >> that returns values of type A. >> >> (M for example can be >> IO: the computations that do input/outputs to find their results, >> State: the computations that use a and update an internal state >> List: more surprisingly, the non-deterministic computations: each >> computation yeilds a list of possible results) >> >> There are a few operators you need for a monad: >> - return : A -> M . It says that any computation model must be able >> to handle the lack of computation. "Do nothing and return this value" >> - bind : M -> (A -> M) -> M >> "If I give you a computation that gives back values in A and for each >> values in A I tell you how to compute a value in B, >> then you can compute a value in B. " >> That's a strong assumption, because it allows to use the whole power >> of Clojure to construct a computation from the result of the first >> computation. >> Some model of computations are more restrictive than monad on that. >> >> From this two operators you can define two others: >> - map : (A -> B) -> M -> M >> "If I give you a function from A to B, then you can transform a >> computation that returns value in A in computation that returns values >> in B." >> (map f compA = (bind compA (fn [x] (return (f x) >> >> - join : M> -> M >> "I can run a subprogram" This is again something quite specific to >> monad as computation devices. (Bind can be constructed from join and >> map) >> They are dynamic programs that can compute a program and run it. >> join compMA = (bind compMA identity) >> >> bind compA f = (join (map f compA)) >> >> All these operators must respect some laws, that are quite natural. >> Like returning a value and starting a computation is the same as starting a >> computation directly from the value: >> >> - (bind (return a) f) = (f a) >> >> >> >> To work out an example, the state monad is a computation that can use >> and modify a state, so: M = S -> [S, A] . I need a state and return >> a new state and a value A. >> return a = (fn [s] -> [s a]) >> bind compA f = >> (fn [s1] -> >> ; we give the state to the first comutation >> (let [[s2 a] (compA s1) >> ; we compute the next computation >> compB (f a)] >> ; we give the state to the second computation >> (compB s2))) >> >> Hope that helps. >> >> Nicolas. > > -- > 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: A difficult Metaphor for Macros (especially for Java people)
Hello, 2010/9/9 Sean Corfield : > On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava wrote: >> I found the easiest way to introduce macros is just to introduce them >> as small syntactic sugaring. For example, getting rid of the explicit >> (fn [] ...) for macros like (with-open file ...). > > Interesting. I don't see any real difference between macros and C > preprocessor stuff and C++ templates at a conceptual level. I think > Clojure macros are much cleaner, but essentially they are similar. So > in the Java world, generics (templates) are not yet widely used > outside the libraries and maybe that's why Java devs find macros hard > to comprehend? I think that even at the conceptual level, the differences are big: a. C/C++ is a "pre-processor". It does a first pass on the code. Only at the end is the C/C++ compiler invoked. In Lisps, there is still this "first pass/second pass" thing, but it's at a waay finer granularity level: the top level form. At the end of the evaluation of each top level form, a new macro may have been defined and can be called immediately by the next top level form. So not only is the "set" of macros not closed in Lisp (and in C/C++, to some extent, it's also not closed, even if rather limited), but it can be expanded during the compilation of the "program". b. The second major difference is that you stay in the same language for writing macros or non macros code in Lisp, whereas you have a preprocessor language with very limited possibilities in C/C++. Same language in the syntactic and semantic level. Macro/non-macro code executions are intermingled. But maybe I'm overemphasizing things. -- 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: A difficult Metaphor for Macros (especially for Java people)
On 09.09.2010, at 09:48, Laurent PETIT wrote: > a. C/C++ is a "pre-processor". It does a first pass on the code. > Only at the end is the C/C++ compiler invoked. In Lisps, there is > still this "first pass/second pass" thing, but it's at a waay finer > granularity level: the top level form. There may or may not be a separation into two passes, that's almost an implementation detail. You can macroexpand a whole top-level expression and then compile it, or else do macroexpansion as to-be-evaluated expressions are compiled. Clojure actually uses the second approach, but you can switch to the first by using clojure.contrib.macro-utils/mexpand-all. And since you can call mexpand-all from a macro, the distinction between the two approaches really becomes blurred. 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
Re: JSON lib of choice?
clj-json is a wrapper for jackson, i've never had a problem with it -- 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
wrap-reload and sandbar session
Hi, It seems that when using ring's wrap-reload to automatically load changes, sandbar session seems to not work. Has anyone else noticed this? Is this a possible bug? I've added ring's wrap-reload to session_demo.clj and the demo breaks. Any work arounds? I would love to be able to use wrap-reload, it is a definite time saver. Thanks, -Rob -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- 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
lisp error system in clojure
Is there any code out there which reproduces common lisp's restart error handling capabilities? -- 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: $'s in java class member names and set!
Yeah. I tried that but it gives what you expect:
Class A defined as follows:
package projects.test;
public class A
{
public boolean y;
public boolean $z;
}
REPL:
user=> (import '(projects.test A))
projects.test.A
user=> (def m (A.))
#'user/m
user=> (set! (. m y) true)
true
user=> (set! (. m $z) true)
java.lang.IllegalArgumentException: No matching field found:
_DOLLARSIGN_z for class projects.test.A
(NO_SOURCE_FILE:0)
user=> (def klass (.getClass m))
#'user/klass
user=> (def fields (.getFields klass))
#'user/fields
user=> (.getName (aget fields 0))
"y"
user=> (.getName (aget fields 1))
"$z"
user=>
Just so everyone knows this isn't a trumped up example. If I can make
this work then I can instantiate JavaFX classes directly without using
JavaFX reflection. I'm exploring a Clojure cover library for JavaFX.
Incidently, some of you might be interested in this:
http://steveonjava.com/javafx-your-way-building-javafx-applications-with-alternative-languages/
Stephen Chin will presenting a talk at JavaOne about using other JVM
languages to call JavaFX.
On Sep 8, 8:05 pm, Sean Devlin wrote:
> Try using reflection to print out what the JVM thinks the field's name
> is. This might help.
>
> On Sep 8, 1:23 am, Jon Seltzer wrote:
>
>
>
> > Suppose you have a class projects.test.A:
>
> > package projects.test;
>
> > public class A
> > {
> > public A(){super();}
> > public boolean y;
> > public boolean $z;
>
> > }
>
> > and I want to use set to update both values:
>
> > user=> (def m (A.)) ; Create a ref m to new instance of A
> > #'user/m
>
> > user=> (set! (. m y) true) ; No problems updating y.
> > true
>
> > user=> (set! (. m $z) true)
> > java.lang.IllegalArgumentException: No matching field found:
> > _DOLLARSIGN_z for class projects.test.A
> > (NO_SOURCE_FILE:0)
>
> > Is there a special syntax for handling java members with $'s in their
> > names?- Hide quoted text -
>
> - Show quoted text -
--
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: A difficult Metaphor for Macros (especially for Java people)
On Sep 8, 5:41 pm, lprefonta...@softaddicts.ca wrote: > Writing tons of XML lines to control behavior of frameworks was also a turn > off. We use Spring to create low-level Java beans but the XML describing > these beans did not change much over time. That is acceptable. I think Lisp is very well suited to being introduced as a replacement for XML. Some XML-based frameworks and tools (notably Spring and Maven) make sure - or are starting to make sure - that XML is not actually required to configure them; you can more or less easily write your own configuration reader that understands your language and plug it in. I actually wrote my own Lisp configuration DSL for Spring and I find that the possibility of having functions, macros, conditionals in your application context is just great ;) Just my €.02 Alessio -- 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: $'s in java class member names and set!
That's probably due to a problem with clojure.core/munge I recently reported on the Dev list [1] -- see a proposed patch attached to my first e-mail in that thread. I notice there still hasn't been any response to that issue... I think I'm just going to go ahead an open a ticket for this tonight. Sincerely, Michał [1] http://groups.google.com/group/clojure-dev/browse_thread/thread/9caab13eafa10f80 -- 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: $'s in java class member names and set!
Ticket created: http://www.assembla.com/spaces/clojure/tickets/433-munge-should-not-munge-$-(which-isjavaidentifierpart)--should-munge---(which-is-not) Sincerely, Michał -- 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: lisp error system in clojure
Hi, On 9 Sep., 05:31, Seth wrote: > Is there any code out there which reproduces common lisp's restart > error handling capabilities? I think clojure.contrib.error-kit is the closest approach. Sincerely Meikel -- 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: Standalone 1.2 contrib
*1* a java-based alternative to maven and ant is gradle. pro: - gradle is a fantastic build-framework contra: - gradle is not leightweight -> even more thirdparty-dependencys - build-scripts are implemented in a groovy-based DSL -> gradle-users have to learn groovy basics i think a clojure-plugin for gradle exists and is called clojuresque (imo it should be named 'clojure-plugin for gradle'). i dont know the exact state of it. *2* to get rid of the dependency on external artifact-repos like ibiblio you could establish your own repo-infrastructure using artifactory. -- 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: A difficult Metaphor for Macros (especially for Java people)
On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT wrote:
> Hello,
>
> 2010/9/9 Sean Corfield :
>> On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava wrote:
>>> I found the easiest way to introduce macros is just to introduce them
>>> as small syntactic sugaring. For example, getting rid of the explicit
>>> (fn [] ...) for macros like (with-open file ...).
>>
>> Interesting. I don't see any real difference between macros and C
>> preprocessor stuff and C++ templates at a conceptual level. I think
>> Clojure macros are much cleaner, but essentially they are similar. So
>> in the Java world, generics (templates) are not yet widely used
>> outside the libraries and maybe that's why Java devs find macros hard
>> to comprehend?
>
> I think that even at the conceptual level, the differences are big:
>
> a. C/C++ is a "pre-processor". It does a first pass on the code.
> Only at the end is the C/C++ compiler invoked. In Lisps, there is
> still this "first pass/second pass" thing, but it's at a waay finer
> granularity level: the top level form. At the end of the evaluation of
> each top level form, a new macro may have been defined and can be
> called immediately by the next top level form. So not only is the
> "set" of macros not closed in Lisp (and in C/C++, to some extent, it's
> also not closed, even if rather limited), but it can be expanded
> during the compilation of the "program".
Of course the real difference is that in Lisp macros you are working
directly on the AST, where in C/C++ macros you're working at the
source level. My understanding of the C/C++ preprocessor is that it
more or less does a string substitution, which *may* lead to a syntax
errors (you often see #define X(y) do { y } while (0); to get around
different limitations), or undesired results, not to mention
unintended variable capture, etc, etc, etc.
The fact that Lisp macros actually operate on the AST means that Lisp
macros can make *changes* to the AST (insert things, remove things,
rearrange things), and *not* just substitute FOO for BAR. This is a
hell of a lot more powerful.
--
http://www.apgwoz.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
Some Problem with Recursion
In order to get some more insight into recursion I wrote the following function but ended up in confusion: (defn prefix->postfix [expr] (if (coll? expr) (let [ [op arg1 arg2] expr] [ (prefix->postfix arg1) (prefix->postfix arg2) op])) expr) I expected the result to be a vector, such as (prefix->postfix '(+ 1 2)) ;; [1 2 +] However, the expression passed as an argument is just returned, at least this is what is looks like: (prefix->postfix '(* 2 3)) ;; --> (* 2 3) (prefix->postfix '(+ 1 (* 2 3))) ;; --> (+ 1 (* 2 3)) I seems there is still some way to go until I can really 'think in recursion'. Therefore I would appreciate if someone could tell me why the above function is not returning the expected result. Stefan -- 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: Some Problem with Recursion
On 9 Wrz, 14:30, Stefan Rohlfing wrote: > In order to get some more insight into recursion I wrote the following > function but ended up in confusion: > > (defn prefix->postfix [expr] > (if (coll? expr) > (let [ [op arg1 arg2] expr] > [ (prefix->postfix arg1) (prefix->postfix arg2) op])) > expr) > > I expected the result to be a vector, such as > (prefix->postfix '(+ 1 2)) > ;; [1 2 +] > > However, the expression passed as an argument is just returned, at > least this is what is looks like: > > (prefix->postfix '(* 2 3)) > ;; --> (* 2 3) > > (prefix->postfix '(+ 1 (* 2 3))) > ;; --> (+ 1 (* 2 3)) > > I seems there is still some way to go until I can really 'think in > recursion'. > > Therefore I would appreciate if someone could tell me why the above > function is not returning the expected result. > > Stefan It return the last expression in the funciton body, which is in this example: expr - which is unchanged input parameter. You probably meant (defn prefix->postfix [expr] (if (coll? expr) (let [ [op arg1 arg2] expr] [ (prefix->postfix arg1) (prefix->postfix arg2) op]) expr)) -- 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: A difficult Metaphor for Macros (especially for Java people)
2010/9/9 Andrew Gwozdziewycz :
> On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT wrote:
>> Hello,
>>
>> 2010/9/9 Sean Corfield :
>>> On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava
>>> wrote:
I found the easiest way to introduce macros is just to introduce them
as small syntactic sugaring. For example, getting rid of the explicit
(fn [] ...) for macros like (with-open file ...).
>>>
>>> Interesting. I don't see any real difference between macros and C
>>> preprocessor stuff and C++ templates at a conceptual level. I think
>>> Clojure macros are much cleaner, but essentially they are similar. So
>>> in the Java world, generics (templates) are not yet widely used
>>> outside the libraries and maybe that's why Java devs find macros hard
>>> to comprehend?
>>
>> I think that even at the conceptual level, the differences are big:
>>
>> a. C/C++ is a "pre-processor". It does a first pass on the code.
>> Only at the end is the C/C++ compiler invoked. In Lisps, there is
>> still this "first pass/second pass" thing, but it's at a waay finer
>> granularity level: the top level form. At the end of the evaluation of
>> each top level form, a new macro may have been defined and can be
>> called immediately by the next top level form. So not only is the
>> "set" of macros not closed in Lisp (and in C/C++, to some extent, it's
>> also not closed, even if rather limited), but it can be expanded
>> during the compilation of the "program".
>
> Of course the real difference is that in Lisp macros you are working
> directly on the AST, where in C/C++ macros you're working at the
> source level. My understanding of the C/C++ preprocessor is that it
> more or less does a string substitution, which *may* lead to a syntax
> errors (you often see #define X(y) do { y } while (0); to get around
> different limitations), or undesired results, not to mention
> unintended variable capture, etc, etc, etc.
>
> The fact that Lisp macros actually operate on the AST means that Lisp
> macros can make *changes* to the AST (insert things, remove things,
> rearrange things), and *not* just substitute FOO for BAR. This is a
> hell of a lot more powerful.
Yeah
--
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: Some Problem with Recursion
Yes. Have someone (for example your editor), do your indentation for you. By typing on tab on a good editor, you would have has: (defn prefix->postfix [expr] (if (coll? expr) (let [ [op arg1 arg2] expr] [ (prefix->postfix arg1) (prefix->postfix arg2) op])) expr) which is easier to diagnose. (At least for me) Have fun with recursion, Nicolas. -- 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: Some Problem with Recursion
The indentation was correct by got messed up when I copying the code. This is how I interpret the function: 'expr' is only returned if (coll? expr) returns 'false', with is not the case with an argument such as '(+ 2 4). Next, this expression is destructured in the 'let' and 'prefix- >postfix called again: [ (prefix->postfix 2) (prefix->postfix 4) +] As 2 and 4 are both not a collection, their values are just returned. This should lead to this final result: [2 4 +] However, no vector is returned, just the initial argument to the function. I really want to understand what I did wrong here :-) Stefan On Sep 9, 9:08 pm, Nicolas Oury wrote: > Yes. > > Have someone (for example your editor), do your indentation for you. > By typing on tab on a good editor, you would have has: > (defn prefix->postfix [expr] > (if (coll? expr) > (let [ [op arg1 arg2] expr] > [ (prefix->postfix arg1) (prefix->postfix arg2) op])) > expr) > > which is easier to diagnose. (At least for me) > > Have fun with recursion, > > Nicolas. -- 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: Some Problem with Recursion
(defn prefix->postfix [expr] (if (coll? expr) (let [ [op arg1 arg2] expr] [ (prefix->postfix arg1) (prefix->postfix arg2) op])) ;; HERE: 2 closing brackets first one close the let. second close the if. expr) In Clojure, (if test expr else) is the if expression. Here, you do (if test then) , which is valid Clojure and add nil as else. So here what happens is you execute the if and after that, whatever eas the value of (coll? expr) you return expr. That's why I told you the indentation was wrong. expr should be at the same level than (if , which would make the error apparent. Best, Nicolas. On Thu, Sep 9, 2010 at 2:27 PM, Stefan Rohlfing wrote: > The indentation was correct by got messed up when I copying the code. > > This is how I interpret the function: > 'expr' is only returned if (coll? expr) returns 'false', with is not > the case with an argument such as '(+ 2 4). > Next, this expression is destructured in the 'let' and 'prefix- >>postfix called again: > > [ (prefix->postfix 2) (prefix->postfix 4) +] > > As 2 and 4 are both not a collection, their values are just returned. > This should lead to this final result: > > [2 4 +] > > However, no vector is returned, just the initial argument to the > function. > > I really want to understand what I did wrong here :-) > > Stefan > > > > On Sep 9, 9:08 pm, Nicolas Oury wrote: >> Yes. >> >> Have someone (for example your editor), do your indentation for you. >> By typing on tab on a good editor, you would have has: >> (defn prefix->postfix [expr] >> (if (coll? expr) >> (let [ [op arg1 arg2] expr] >> [ (prefix->postfix arg1) (prefix->postfix arg2) op])) >> expr) >> >> which is easier to diagnose. (At least for me) >> >> Have fun with recursion, >> >> Nicolas. > > -- > 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 -- Sent from an IBM Model M, 15 August 1989. -- 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: Some Problem with Recursion
On 9 Wrz, 15:27, Stefan Rohlfing wrote: > The indentation was correct by got messed up when I copying the code. > > This is how I interpret the function: > 'expr' is only returned if (coll? expr) returns 'false', with is not > the case with an argument such as '(+ 2 4). > Next, this expression is destructured in the 'let' and 'prefix- > > >postfix called again: > > [ (prefix->postfix 2) (prefix->postfix 4) +] > > As 2 and 4 are both not a collection, their values are just returned. > This should lead to this final result: > > [2 4 +] > > However, no vector is returned, just the initial argument to the > function. > > I really want to understand what I did wrong here :-) > > Stefan Hello. You understand recursion correctly, the issue is with lisp syntax :) Your code: (defn prefix->postfix [expr] (if (coll? expr) (let [ [op arg1 arg2] expr] [ (prefix->postfix arg1) (prefix->postfix arg2) op])) expr) Translated to pseudocode it does: def f(expr): if expr is collection: calculate vector and ignore the result else: calculate nil and ignore it return expr It's because code should look like this: (defn prefix->postfix [expr] (if (coll? expr) (let [ [op arg1 arg2] expr] [ (prefix->postfix arg1) (prefix->postfix arg2) op]) expr)) Notice the difference with the placing of the penultimate ")" - this difference would be easier to notice, if you indent your code automaticaly - by emacs for example. Becouse of that paren if in your function is version with only one branch - this if would evaluate to nil if expr will be not colleciton. But no matter what the expr is, after the if there is expr and (as a last expression in the function body) it is what the function returns. -- 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: A difficult Metaphor for Macros (especially for Java people)
On 9 Wrz, 14:25, Andrew Gwozdziewycz wrote:
> The fact that Lisp macros actually operate on the AST means that Lisp
> macros can make *changes* to the AST (insert things, remove things,
> rearrange things), and *not* just substitute FOO for BAR. This is a
> hell of a lot more powerful.
>
> --http://www.apgwoz.com
To be fair to C and C++ they allow changing AST:
#define UNLESS(x,y) {if (!(x)) {y;} };
This macro changes (UNLESS x y) to (if (not x) y) - this is different
AST trees.
The only difference I see is that in C you have to work with
characters, when in lisp you work with lists, and that in C you can
only use preprocessor directives at compile time (you can't output
diffrent code in macro depending on the structure of its arguments),
when in lisp you can use lisp at compile time to change what code will
be created by macro.
--
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
Simple things should be simple
I've spent far more time evaluating clojure than I had expected to. Part of the problem is that I'm of two minds. I love the language - it seems to mix in just the right bits of LISP, data structures from modern dynamic languages, and functional programming. On the other hand, I'm repelled by the java infrastructure around it. Having been brought up on Unix systems and the software tools approach (well, exposed to them relatively early, anyway), I'm a firm believer that simple things should be simple, and complex things should be possible. That's fundamental, but the Java world seems to have forgotten it, and everything is targeted at building large systems. If you want to do something simple, it seems you still have to go through the dance required to do complex things. So, I'm asking for someone to show me I'm wrong. In particular, if I wanted to deploy a simple web app (the classic "Hello World") on your favorite java or clojure web framework, how many lines of text do I have to deal with? Most importantly, how many of those are program text, and how many are framework boilerplate(*)? Finally, how many tools do I have to use to get it deployed(+)? For good Unix tools, the answers are 3, 0 and 1. 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: A difficult Metaphor for Macros (especially for Java people)
On Thu, 9 Sep 2010 07:04:00 -0700 (PDT) ajuc wrote: > [In C] you can't output different code in macro depending on the > structure of its arguments That, of course, is a *crucial* difference. Think about the same restriction outside the macro environment: what would programming be like in a language where a function couldn't output different values depending on its arguments? 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: Simple things should be simple
2010/9/9 Mike Meyer : > I've spent far more time evaluating clojure than I had expected > to. Part of the problem is that I'm of two minds. I love the language > - it seems to mix in just the right bits of LISP, data structures from > modern dynamic languages, and functional programming. > > On the other hand, I'm repelled by the java infrastructure around > it. Having been brought up on Unix systems and the software tools > approach (well, exposed to them relatively early, anyway), I'm a firm > believer that simple things should be simple, and complex things > should be possible. That's fundamental, but the Java world seems to > have forgotten it, and everything is targeted at building large > systems. If you want to do something simple, it seems you still have > to go through the dance required to do complex things. > > So, I'm asking for someone to show me I'm wrong. In particular, if I > wanted to deploy a simple web app (the classic "Hello World") on your > favorite java or clojure web framework, how many lines of text do I > have to deal with? Most importantly, how many of those are program > text, and how many are framework boilerplate(*)? Finally, how many > tools do I have to use to get it deployed(+)? Is there a limit on the line length ? :-p > > For good Unix tools, the answers are 3, 0 and 1. > > > *) If some tools generates files that are used, only files that I have > to change count, but all the lines in those files count. Blank lines > added to improve readability don't count. > +) Not counting whatever is required to get the web server ready to > deploy arbitrary applications (war files or whatever), or a text > editor, so long as it's *any* text editor, and not a specific one. > -- > Mike Meyer 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 -- 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
Knowing in advance the complexity of count
Dear all, I want to write a generic code that use count when it is O(1) and not when it is not O(n), is it a way to do so? Best regards, Nicolas -- 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: Simple things should be simple
Hi, I don't know what the full definition of "deploy" is, but here is an example, that should serve as a starting point: http://m.3wa.com/?p=472 Sincerely Meikel -- 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: Knowing in advance the complexity of count
Hi, On 9 Sep., 16:45, Nicolas Oury wrote: > is it a way to do so? You can check the Counted marker interface for clojure collections. But this won't cover Strings etc. More information here: http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L489 Sincerely Meikel -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 10:07 AM, Mike Meyer <
mwm-keyword-googlegroups.620...@mired.org> wrote:
> So, I'm asking for someone to show me I'm wrong. In particular, if I
> wanted to deploy a simple web app (the classic "Hello World") on your
> favorite java or clojure web framework, how many lines of text do I
> have to deal with? Most importantly, how many of those are program
> text, and how many are framework boilerplate(*)? Finally, how many
> tools do I have to use to get it deployed(+)?
>
If you're going for simplicity over robustness and you have lein installed,
all you need to do is the following:
lein new nano-web
Edit your project.clj
(defproject nano-web "1.0.0-SNAPSHOT"
:dependencies [[org.clojure/clojure "1.2.0"]
[org.clojure/clojure-contrib "1.2.0"]
[ring "0.2.5"]])
So far we have 4 lines to define our dependencies. Edit
src/core/nano_web.clj
(ns nano-web.core
(use [ring.adapter.jetty :only [run-jetty]]
[ring.util.response :only [response]]))
(defn hello-world [req]
(response "Hello World!"))
(defonce server (run-jetty hello-world {:port 8080 :join? false}))
That's the 8 lines of actual code needed to have a full functioning web
application. Let's start it:
lein repl
user=> (load "nano_web/core")
So 12 lines of code and 2 command line operations, 1 expression at the REPL.
Cheers,
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
Re: Simple things should be simple
On Thu, 9 Sep 2010 07:46:22 -0700 (PDT) Meikel Brandmeyer wrote: > Hi, > > I don't know what the full definition of "deploy" is, but here is an > example, that should serve as a starting point: http://m.3wa.com/?p=472 That's a good example of simple things not being simple. Before I've seen a single line of code, I see I need to create an order of magnitude more lines of boilerplate than lines of code in the application using a framework that makes simple things simple. 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: Simple things should be simple
Hi Mike, Could you perhaps present a counter-example of greater simplicity ? Edmund On Thu, Sep 9, 2010 at 4:03 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > On Thu, 9 Sep 2010 07:46:22 -0700 (PDT) > Meikel Brandmeyer wrote: > > > Hi, > > > > I don't know what the full definition of "deploy" is, but here is an > > example, that should serve as a starting point: http://m.3wa.com/?p=472 > > That's a good example of simple things not being simple. > > Before I've seen a single line of code, I see I need to create an > order of magnitude more lines of boilerplate than lines of code in the > application using a framework that makes simple things simple. > >-- > Mike Meyer > 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 > -- 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: Knowing in advance the complexity of count
Thank you very much. Never looked closely at count definition. I assumed it was a forawrd to .count of Counted, which explains my problem. I kind of remembered the O(1) of Counted and get mixed up. Best regards, Nicolas. On Thu, Sep 9, 2010 at 3:50 PM, Meikel Brandmeyer wrote: > Hi, > > On 9 Sep., 16:45, Nicolas Oury wrote: > >> is it a way to do so? > > You can check the Counted marker interface for clojure collections. > But this won't cover Strings etc. More information here: > http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L489 > > Sincerely > Meikel > > -- > 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 -- Sent from an IBM Model M, 15 August 1989. -- 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: Simple things should be simple
2010/9/9 Mike Meyer : > I've spent far more time evaluating clojure than I had expected > to. Part of the problem is that I'm of two minds. I love the language > - it seems to mix in just the right bits of LISP, data structures from > modern dynamic languages, and functional programming. > > On the other hand, I'm repelled by the java infrastructure around > it. Having been brought up on Unix systems and the software tools > approach (well, exposed to them relatively early, anyway), I'm a firm > believer that simple things should be simple, and complex things > should be possible. That's fundamental, but the Java world seems to > have forgotten it, and everything is targeted at building large > systems. If you want to do something simple, it seems you still have > to go through the dance required to do complex things. > > So, I'm asking for someone to show me I'm wrong. In particular, if I > wanted to deploy a simple web app (the classic "Hello World") on your > favorite java or clojure web framework, how many lines of text do I > have to deal with? Most importantly, how many of those are program > text, and how many are framework boilerplate(*)? Finally, how many > tools do I have to use to get it deployed(+)? > > For good Unix tools, the answers are 3, 0 and 1. Out of curiosity, can you explicit the numbers 3, 0 and 1, so that it'll be easier to see whether we're compared cats with cats ? -- 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: Simple things should be simple
I'm not sure what your point is. If I want to write a hello world php script on a unix system, but apache and mod_php weren't setup. I'd first have to install them and configure them. This is only easy these days because most linux come with apache installed, php installed, mod_php preconfigured for you. You want something simple that requires no config, this can happen during dev. Just write the hello world, and start the embedded jetty using ring. If you really just want to serve hello world, you don't need to resort to deploy a war file. you can just take that hello world script, start the embeded jetty and mod_proxy to it. That's hardly the "production way", but then I don't know that writing a web app that prints 1 line is really very production either. Now it's true that there are some overhead to make sure your webapp produce a war file and can be deployed to ANY containers. It's not 3/1/0 as you claimed. But it's a pretty small part of the web app dev cycle in my experience. I mean, it's not like I spend 90% of my time writing config files and 10% of my time writing clojure/groovy/java/(insert whatever jvm language) code, web dev or otherwise. On Thu, Sep 9, 2010 at 11:03 AM, Mike Meyer wrote: > On Thu, 9 Sep 2010 07:46:22 -0700 (PDT) > Meikel Brandmeyer wrote: > >> Hi, >> >> I don't know what the full definition of "deploy" is, but here is an >> example, that should serve as a starting point: http://m.3wa.com/?p=472 > > That's a good example of simple things not being simple. > > Before I've seen a single line of code, I see I need to create an > order of magnitude more lines of boilerplate than lines of code in the > application using a framework that makes simple things simple. -- Omnem crede diem tibi diluxisse supremum. -- 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: Simple things should be simple
I'm not sure what your point is. If I want to write a hello world php script on a unix system, but apache and mod_php weren't setup. I'd first have to install them and configure them. This is only easy these days because most linux come with apache installed, php installed, mod_php preconfigured for you. You want something simple that requires no config, this can happen during dev. Just write the hello world, and start the embedded jetty using ring. If you really just want to serve hello world, you don't need to resort to deploy a war file. you can just take that hello world script, start the embeded jetty and mod_proxy to it. That's hardly the "production way", but then I don't know that writing a web app that prints 1 line is really very production either. Now it's true that there are some overhead to make sure your webapp produce a war file and can be deployed to ANY containers. It's not 3/1/0 as you claimed. But it's a pretty small part of the web app dev cycle in my experience. I mean, it's not like I spend 90% of my time writing config files and 10% of my time writing clojure/groovy/java/(insert whatever jvm language) code, web dev or otherwise. On Thu, Sep 9, 2010 at 11:03 AM, Mike Meyer wrote: > On Thu, 9 Sep 2010 07:46:22 -0700 (PDT) > Meikel Brandmeyer wrote: > >> Hi, >> >> I don't know what the full definition of "deploy" is, but here is an >> example, that should serve as a starting point: http://m.3wa.com/?p=472 > > That's a good example of simple things not being simple. > > Before I've seen a single line of code, I see I need to create an > order of magnitude more lines of boilerplate than lines of code in the > application using a framework that makes simple things simple. -- Omnem crede diem tibi diluxisse supremum. -- 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: Knowing in advance the complexity of count
actually there is a function called counted? Sunil. On Thu, Sep 9, 2010 at 8:59 PM, Nicolas Oury wrote: > Thank you very much. > > Never looked closely at count definition. > > I assumed it was a forawrd to .count of Counted, which explains my problem. > > I kind of remembered the O(1) of Counted and get mixed up. > > Best regards, > > Nicolas. > > On Thu, Sep 9, 2010 at 3:50 PM, Meikel Brandmeyer wrote: > > Hi, > > > > On 9 Sep., 16:45, Nicolas Oury wrote: > > > >> is it a way to do so? > > > > You can check the Counted marker interface for clojure collections. > > But this won't cover Strings etc. More information here: > > > http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L489 > > > > Sincerely > > Meikel > > > > -- > > 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 > > > > -- > Sent from an IBM Model M, 15 August 1989. > > -- > 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: wrap-reload and sandbar session
Rob, Ring stores session data in an atom. Reloading re-defines the atom to be empty. Sandbar uses Ring's session store. I have made a small change to Ring in my branch which fixes this problem. See http://github.com/brentonashworth/ring/commit/ebcdb3ec8adfc5c82d5fd6031f444a105701a8e0. I don't see any problems with this change and will submit it as a patch on the Ring mailing list and see what the people over there think it. Maybe there is another way around this problem. So, the work-around would be to fork Ring. Make this change in your branch and then do lein jar && lein install. Then in your project remember to do lein clean && lein deps. This will get what you want working in development and is still compatible when you go to production. Brenton On Sep 8, 5:32 pm, Rob McBride wrote: > Hi, > > It seems that when using ring's wrap-reload to automatically load changes, > sandbar session seems to not work. Has anyone else noticed this? Is this a > possible bug? > > I've added ring's wrap-reload to session_demo.clj and the demo breaks. > > Any work arounds? I would love to be able to use wrap-reload, it is a > definite time saver. > > Thanks, > -Rob > > -- > Please avoid sending me Word or PowerPoint attachments. > Seehttp://www.gnu.org/philosophy/no-word-attachments.html -- 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: Simple things should be simple
On Thu, 9 Sep 2010 10:59:28 -0400
David Nolen wrote:
> If you're going for simplicity over robustness and you have lein installed,
> all you need to do is the following:
>
> lein new nano-web
Yup - the goal is simplicity. Robustness is important, but I expect
the web server to take care of that. What I'm really expecting to lose
here is performance.
> Edit your project.clj
>
> (defproject nano-web "1.0.0-SNAPSHOT"
> :dependencies [[org.clojure/clojure "1.2.0"]
> [org.clojure/clojure-contrib "1.2.0"]
> [ring "0.2.5"]])
>
> So far we have 4 lines to define our dependencies. Edit
> src/core/nano_web.clj
You mean src/nano_web/core.clj.
> (ns nano-web.core
> (use [ring.adapter.jetty :only [run-jetty]]
>[ring.util.response :only [response]]))
>
> (defn hello-world [req]
> (response "Hello World!"))
>
> (defonce server (run-jetty hello-world {:port 8080 :join? false}))
>
> That's the 8 lines of actual code needed to have a full functioning web
> application. Let's start it:
The blank lines don't count, so it's six lines of code.
> lein repl
> user=> (load "nano_web/core")
And two tools - lein and clojure itself.
So we go from 3, 0, 1 to 6, 4, 2. I'm not sure that qualifies as
simple, but at least there's less boilerplate for the tools than there
is actual source code.
Thanks for the answer.
And, since I forgot, thanks to Meikel Brandmeyer for his earlier
answer as well.
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: Simple things should be simple
On Thu, 9 Sep 2010 16:28:48 +0100 Edmund Jackson wrote: > Hi Mike, > > Could you perhaps present a counter-example of greater simplicity ? $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh #!/bin/sh echo 'Content-type: text/plain\n' echo Hello World ^D $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh Done. Three lines of source code. 0 lines of framework setup. 1 tool (sh). Pretty much the same thing works for python, perl, etc. It's about as robust as can be asked for - that's the nature of apache. Performance is going to be mediocre at best. That's the trade-off for simplicity. 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: Simple things should be simple
How are you going to handle session? How are you going to handle database from a echo script? I mean, I can counter by just create a hello.html in apache and put "hello world" in there. It's 1 line, 0 to deploy. And it's FAST. It's even cached and uses no cpu time being served. that doesn't really mean that using web dev only using html is simple or is desirable. Having done web dev using cgi long ago, I don't think I want to go back to that. On Thu, Sep 9, 2010 at 11:47 AM, Mike Meyer wrote: > On Thu, 9 Sep 2010 16:28:48 +0100 > Edmund Jackson wrote: > >> Hi Mike, >> >> Could you perhaps present a counter-example of greater simplicity ? > > $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh > #!/bin/sh > > echo 'Content-type: text/plain\n' > echo Hello World > ^D > $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh > > Done. Three lines of source code. 0 lines of framework setup. 1 tool > (sh). Pretty much the same thing works for python, perl, etc. It's > about as robust as can be asked for - that's the nature of > apache. Performance is going to be mediocre at best. That's the > trade-off for simplicity. > > -- > Mike Meyer 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 -- Omnem crede diem tibi diluxisse supremum. -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 11:38 AM, Mike Meyer wrote: > Yup - the goal is simplicity. Robustness is important, but I expect > the web server to take care of that. What I'm really expecting to lose > here is performance. performance? > You mean src/nano_web/core.clj. > Good catch. > So we go from 3, 0, 1 to 6, 4, 2. And looking over your later post on using apache + cgi. 6, 4, 2 is for a *very* high performance HelloWorld that can envolve sanely over time (5000-7000 req second on a naive benchmark on a new-ish laptop). Can't say that much about serving bash shell scripts over apache. 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
Re: Simple things should be simple
Lines of code are a terrible metric for language complexity. If I
write a function and abstract away half the code, have I made Clojure
twice as simple?
If you want to really evaluate Clojure, write a non-trivial
application and see whether the complexity is still manageable. Code
golf doesn't tell you anything.
Zach
On Sep 9, 8:38 am, Mike Meyer wrote:
> On Thu, 9 Sep 2010 10:59:28 -0400
>
> David Nolen wrote:
> > If you're going for simplicity over robustness and you have lein installed,
> > all you need to do is the following:
>
> > lein new nano-web
>
> Yup - the goal is simplicity. Robustness is important, but I expect
> the web server to take care of that. What I'm really expecting to lose
> here is performance.
>
> > Edit your project.clj
>
> > (defproject nano-web "1.0.0-SNAPSHOT"
> > :dependencies [[org.clojure/clojure "1.2.0"]
> > [org.clojure/clojure-contrib "1.2.0"]
> > [ring "0.2.5"]])
>
> > So far we have 4 lines to define our dependencies. Edit
> > src/core/nano_web.clj
>
> You mean src/nano_web/core.clj.
>
> > (ns nano-web.core
> > (use [ring.adapter.jetty :only [run-jetty]]
> > [ring.util.response :only [response]]))
>
> > (defn hello-world [req]
> > (response "Hello World!"))
>
> > (defonce server (run-jetty hello-world {:port 8080 :join? false}))
>
> > That's the 8 lines of actual code needed to have a full functioning web
> > application. Let's start it:
>
> The blank lines don't count, so it's six lines of code.
>
> > lein repl
> > user=> (load "nano_web/core")
>
> And two tools - lein and clojure itself.
>
> So we go from 3, 0, 1 to 6, 4, 2. I'm not sure that qualifies as
> simple, but at least there's less boilerplate for the tools than there
> is actual source code.
>
> Thanks for the answer.
>
> And, since I forgot, thanks to Meikel Brandmeyer for his earlier
> answer as well.
>
> --
> Mike Meyer 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: Simple things should be simple
On Thu, 9 Sep 2010 11:30:51 -0400 Wilson MacGyver wrote: > I'm not sure what your point is. If I want to write a hello world php > script on a unix > system, but apache and mod_php weren't setup. I'd first have to install them > and configure them. That simple things should be simple. Setting up a web server - and associated tools - to the point that you can install applications on it isn't necessarily simple, so I don't expect it to be simple. On the other hand, I only have to do that *once*, not once per application (at least, I hope I don't have to do it once per application!). > This is only easy these days because most linux come with apache installed, > php installed, mod_php preconfigured for you. Just one of the reasons there's nary a linux box to be found in my house. > You want something simple that requires no config, this can happen > during dev. Just write the hello world, and start the embedded jetty using > ring. David Nolan just described that. It's not bad at all. Given a shell script to launch it, it might even be usable for the projects I have in mind. It would have been a lot more impressive if leinigen hadn't made at least two incorrect assumptions about what I wanted to do in other operations that I'd have to fix. > If you really just want to serve hello world, you don't need to resort to > deploy a war file. you can just take that hello world script, start the > embeded > jetty and mod_proxy to it. That's hardly the "production way", but > then I don't know that writing a web app that prints 1 line is really > very production > either. But again, running a proxy just to wire up a simple web app takes you out of the realm of "simple". There are production web services that print a single line. Well, ok, these days they print a line or two of controls and 20 lines of advertising as well, but still wind up printing one value of interest: current temperature at some location, current stock price for some stock, current exchange rate for some currency, etc. I chose hello world because the question is more about how much overhead using even "simple" java infrastructure adds than about the application. > Now it's true that there are some overhead to make sure your webapp produce > a war file and can be deployed to ANY containers. It's not 3/1/0 as you > claimed. A) I didn't claim I could do this with war files - those are a java thing, and it's the java infrastructure that annoys me; I claimed (and just posted the example) that I could do it with Unix tools. B) It's 3/0/1, not 3/1/0. > But it's a pretty small part of the web app dev cycle in my experience. I > mean, > it's not like I spend 90% of my time writing config files and 10% of my time > writing clojure/groovy/java/(insert whatever jvm language) code, web dev or > otherwise. Of course not - you don't spend all your time doing simple projects. Nobody does. But simple projects taking 10 times as long as they should because of that still sucks. 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: Simple things should be simple
On Thu, Sep 9, 2010 at 8:38 AM, Mike Meyer
wrote:
> And two tools - lein and clojure itself.
I'm not sure Clojure should be counted separately since you're not
installing it yourself.
> So we go from 3, 0, 1 to 6, 4, 2. I'm not sure that qualifies as
> simple, but at least there's less boilerplate for the tools than there
> is actual source code.
Really I think your complaint boils down to not being able to modify
the classpath at runtime. If the JVM had a real load-path like other
lisps offer then this would be enough:
(use 'ring.adapter.jetty 'ring.util.response)
(run-jetty (constantly (response "hello world"))
{:port 8080 :join? false})
...and we're back to three lines.
Now I'm not defending the fact that the classpath is fixed at
JVM-launch time--it's an awful hack that is an embarrassment to the
awesome engineering prowess that has gone in to other parts of the
JVM. But we do have tools to work around that flaw, and it's good to
recognize the root of the problem rather than its symptoms.
-Phil
--
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: Simple things should be simple
You assume the presence of a configured web server but not a text editor ? The only constructive thing I can say is that the set of things that may be considered simple in the clojure setup above is vastly greater than the alternative you present. If the cost is a 4 line 'boilerplate' (and I'm pointedly not going to compare that to /etc/apache/conf.d) I think its a low price. On Thu, Sep 9, 2010 at 4:47 PM, Mike Meyer wrote: > On Thu, 9 Sep 2010 16:28:48 +0100 > Edmund Jackson wrote: > > > Hi Mike, > > > > Could you perhaps present a counter-example of greater simplicity ? > > $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh > #!/bin/sh > > echo 'Content-type: text/plain\n' > echo Hello World > ^D > $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh > > Done. Three lines of source code. 0 lines of framework setup. 1 tool > (sh). Pretty much the same thing works for python, perl, etc. It's > about as robust as can be asked for - that's the nature of > apache. Performance is going to be mediocre at best. That's the > trade-off for simplicity. > > -- > Mike Meyer > 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: Simple things should be simple
On Thu, 9 Sep 2010 11:57:23 -0400 David Nolen wrote: > On Thu, Sep 9, 2010 at 11:38 AM, Mike Meyer wrote: > > > Yup - the goal is simplicity. Robustness is important, but I expect > > the web server to take care of that. What I'm really expecting to lose > > here is performance. > performance? Yup: > And looking over your later post on using apache + cgi. 6, 4, 2 is for a > *very* high performance HelloWorld that can envolve sanely over time > (5000-7000 req second on a naive benchmark on a new-ish laptop). Can't say > that much about serving bash shell scripts over apache. Right. Delivering real performance isn't simple :-). The thing is, the same thing works for python, or perl, or any number of other things. Those you can switch to mod_ or an external CGI daemon running embedded or similar things to get performance. On the other hand, tossing a CGI shell script onto a heyu installation to read an outside thermometer is a perfectly reasonable thing to do. I don't expect even 10 requests a second for the temperature on my porch. 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: Simple things should be simple
On Thu, Sep 9, 2010 at 12:05 PM, Mike Meyer wrote: > On Thu, 9 Sep 2010 11:30:51 -0400 >> Now it's true that there are some overhead to make sure your webapp produce >> a war file and can be deployed to ANY containers. It's not 3/1/0 as you >> claimed. > > A) I didn't claim I could do this with war files - those are a java > thing, and it's the java infrastructure that annoys me; I claimed (and > just posted the example) that I could do it with Unix tools. B) It's > 3/0/1, not 3/1/0. sorry, I should've been more clear, I meant to say that "creating war files isn't not 3/0/1 lines compared to your unix tools.". I poorly worded that. -- Omnem crede diem tibi diluxisse supremum. -- 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: Simple things should be simple
On Thu, 9 Sep 2010 09:03:38 -0700 (PDT) Zach Tellman wrote: > Lines of code are a terrible metric for language complexity. If I > write a function and abstract away half the code, have I made Clojure > twice as simple? Ah, I'm sorry - I'm not looking at *language* complexity. I'm looking at the complexity of the java/clojure *environment*. It seems to take a lot non-clojure boilerplate to do *anything* in java-land than seems reasonable to me. But I don't know javaland very well, which is why I asked for other people's opinions. > If you want to really evaluate Clojure, write a non-trivial > application and see whether the complexity is still manageable. Code > golf doesn't tell you anything. Been there, done that. More than once. Well, maybe, depending on your definition of "trivial". http://blog.mired.org/ Clojure great. No questions about that. WAR files, CLASSPATHs, having to wrap *every little command* in it's own script - that's what I'm looking at. 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: Simple things should be simple
On Thu, 9 Sep 2010 09:06:49 -0700
Phil Hagelberg wrote:
> On Thu, Sep 9, 2010 at 8:38 AM, Mike Meyer
> wrote:
> > And two tools - lein and clojure itself.
> I'm not sure Clojure should be counted separately since you're not
> installing it yourself.
Installation isn't the issue, use is the issue. I have to run or
interact with clojure at some point. Since the same is true for any
implementation language, it could be dropped as well.
> > So we go from 3, 0, 1 to 6, 4, 2. I'm not sure that qualifies as
> > simple, but at least there's less boilerplate for the tools than there
> > is actual source code.
> Really I think your complaint boils down to not being able to modify
> the classpath at runtime. If the JVM had a real load-path like other
> lisps offer then this would be enough:
>
> (use 'ring.adapter.jetty 'ring.util.response)
> (run-jetty (constantly (response "hello world"))
>{:port 8080 :join? false})
>
> ...and we're back to three lines.
Yes, that would help. But I'm not sure that means I wouldn't have to
use lein at all? And it's more the "more lines of config than source"
than the lines of source that's an issue.
> Now I'm not defending the fact that the classpath is fixed at
> JVM-launch time--it's an awful hack that is an embarrassment to the
> awesome engineering prowess that has gone in to other parts of the
> JVM. But we do have tools to work around that flaw, and it's good to
> recognize the root of the problem rather than its symptoms.
Fair enough. But having to use those tools is what keeps simple things
from being simple.
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: Simple things should be simple
On Thu, Sep 9, 2010 at 12:22 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > Clojure great. No questions about that. WAR files, CLASSPATHs, having > to wrap *every little command* in it's own script - that's what I'm > looking at. I've already shown that you don't need WAR files. If you really, really hate the CLASSPATH you should look at cake. It does require ruby, but it let's you essentially write "instant-on" Clojure shell scripts as well as give you access to things like the working shell directory if that's the way you want to work with Clojure. #!/usr/bin/env cake run (println "Hello world!") Other people have felt your pain and have started building solutions. You can help them out by using those solutions and giving feedback :) 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
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 2, 4:51 pm, Isaac Gouy wrote: > On Sep 1, 9:46 pm, John Fingerhut wrote: > > > Thanks to many people on this list in Aug 2009 who helped improve my code, > > to Johannes Friestad for writing a nice fast Clojure program using deftype > > for the n-body problem, to Isaac Gouy for setting up the shootout web site > > to accept Clojure submissions, and to my having more time than good sense to > > work on this, there are now Clojure programs for 5 of the 10 shootout web > > site benchmark problems. > > iirc Clojure won't show up on the summary pages until there are 7 > programs implemented. > > Nontheless I've put Clojure on the home page. > > > You can see a brief summary of results comparing > > run time, memory, and code size against "Java 6 -server" here: > > >http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=clo... Clojure now shows up on the summary pages http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php?calc=chart&java=on&scala=on&sbcl=on&clojure=on&python3=on&jruby=on -- 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: Simple things should be simple
Mike, Your point has been made, simple things are simple. When you need to print "hello world" you don't need to bring Clojure into the picture. You could have given a much simpler example of needing to print "hello world" on the command line. echo "hello world" is much simpler than what you would need to do in Clojure. When faced with any problem to solve, you have to look at the tools you have available and then determine what the simplest solution will be. In your case, all of the software you need is already installed, configured and running. So it's simple. If you gave me a system with Tomcat installed, configured and running then I could do the exact same thing. It has nothing to do with Java, it has to do with what you are given to work with. For David Nolan's example above, what you are getting compared to how much code you have to write is actually quite amazing. And when you start that way, the answer to the question "What if I wanted to do X?" is usually much simpler. And I agree with everything Zach said above. Brenton On Sep 9, 9:22 am, Mike Meyer wrote: > On Thu, 9 Sep 2010 09:03:38 -0700 (PDT) > > Zach Tellman wrote: > > Lines of code are a terrible metric for language complexity. If I > > write a function and abstract away half the code, have I made Clojure > > twice as simple? > > Ah, I'm sorry - I'm not looking at *language* complexity. I'm looking > at the complexity of the java/clojure *environment*. It seems to take > a lot non-clojure boilerplate to do *anything* in java-land than seems > reasonable to me. But I don't know javaland very well, which is why I > asked for other people's opinions. > > > If you want to really evaluate Clojure, write a non-trivial > > application and see whether the complexity is still manageable. Code > > golf doesn't tell you anything. > > Been there, done that. More than once. Well, maybe, depending on your > definition of "trivial".http://blog.mired.org/ > > Clojure great. No questions about that. WAR files, CLASSPATHs, having > to wrap *every little command* in it's own script - that's what I'm > looking at. > > -- > Mike Meyer 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: Simple things should be simple
On Thu, 9 Sep 2010 11:52:30 -0400 Wilson MacGyver wrote: > How are you going to handle session? How are you going to handle > database from a echo script? What, you've never generated HTML directly from an SQL script? Any good SQL system will do that for you. All of these things are *possible* using CGI and a shell script. That doesn't mean it's desirable - I don't use the shell much for anything that requires more than two loops myself. The point is that these things aren't *required* for all applications, and I shouldn't have to deal with complexity they incur if I don't need them. Simple things should be simple. It seems to me as if once you drag java into the equation, nothing is simple. I'm trying to figure out if that's correct or not. > I mean, I can counter by just create a hello.html in apache > and put "hello world" in there. It's 1 line, 0 to deploy. And it's FAST. > It's even cached and uses no cpu time being served. Yup. And you can use SSI to do other simple things as well. I never used SSI - I pretty much detested what it did to web servers - but it was very popular, because it made *simple things simple*. > that doesn't really mean that using web dev only using html > is simple or is desirable. Actually, it simple *if you're doing simple things*. Yeah, the Java tools may rock if you're doing complicated, enterprise-style applications. Having to deal with that level of complexity to turn off my garage light before I go to bed sucks. > Having done web dev using cgi long ago, I don't think I want to go back > to that. I'm not asking you to. I'm asking if there's anything that's that simple that can be used for simple tasks if your application runs on the JVM. 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: $'s in java class member names and set!
I suspect $ is in munge because Rich and company may want to use it as a special reader character. $'s used to access inner classes work fine. I'd be fine with that as long as there's still a way to access Java identifiers with dollar signs (perhaps a special macro). On Sep 9, 3:49 am, Michał Marczyk wrote: > That's probably due to a problem with clojure.core/munge I recently > reported on the Dev list [1] -- see a proposed patch attached to my > first e-mail in that thread. I notice there still hasn't been any > response to that issue... I think I'm just going to go ahead an open a > ticket for this tonight. > > Sincerely, > Michał > > [1]http://groups.google.com/group/clojure-dev/browse_thread/thread/9caab... -- 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: lisp error system in clojure
exact what i want! Heres a nice link which describes it http://pragprog.com/magazines/2009-07/when-things-go-wrong On Sep 9, 6:20 am, Meikel Brandmeyer wrote: > Hi, > > On 9 Sep., 05:31, Seth wrote: > > > Is there any code out there which reproduces common lisp's restart > > error handling capabilities? > > I think clojure.contrib.error-kit is the closest approach. > > Sincerely > Meikel -- 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: A difficult Metaphor for Macros (especially for Java people)
On Thu, Sep 9, 2010 at 10:04 AM, ajuc wrote:
>
>
> On 9 Wrz, 14:25, Andrew Gwozdziewycz wrote:
>> The fact that Lisp macros actually operate on the AST means that Lisp
>> macros can make *changes* to the AST (insert things, remove things,
>> rearrange things), and *not* just substitute FOO for BAR. This is a
>> hell of a lot more powerful.
>>
>> --http://www.apgwoz.com
>
> To be fair to C and C++ they allow changing AST:
>
> #define UNLESS(x,y) {if (!(x)) {y;} };
>
> This macro changes (UNLESS x y) to (if (not x) y) - this is different
> AST trees.
>
> The only difference I see is that in C you have to work with
> characters, when in lisp you work with lists, and that in C you can
> only use preprocessor directives at compile time (you can't output
> diffrent code in macro depending on the structure of its arguments),
> when in lisp you can use lisp at compile time to change what code will
> be created by macro.
Well, C preprocessor macros don't really *change* the AST, it
*affects* the source *before* it's passed to the compiler (the
compiler creates the AST). You've also stumbled on the most important
difference between the two types--those differences make Lisp style
macros far more powerful.
--
http://www.apgwoz.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
Re: Simple things should be simple
Mike, If you are happy with cgi and if we posit that clojure is a compiled language and leiningen is the same as make. The I submit the following bit of fluff: At a prompt: $ lein new hw $ cd hw $ lein deps Then edit project.clj to look as follows: (defproject hw "0.0.1" :description "The smallest hello world that will work." :dependencies [[org.clojure/clojure "1.2.0"] [org.clojure/clojure-contrib "1.2.0"]] :aot [hw.core] :main hw.core) Then edit hw/core.clj as follows: (ns hw.core (:gen-class)) (defn -main [& args] (println "Hello World.")) At a prompt: $ lein uberjar And create the following shell script hw.sh #! /bin/bash java -jar hw-0.0.1-standalone.jar I'm sure you can wire the shell script into your apache. And this isn't as short as a shell/python/perl script that does print or echo. I also fear this is descending into perl golf, but I fancied having a crack at this anyway on a brain fried day. cheers, Bruce -- 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: Simple things should be simple
I think the point is missed with this example. Given your hello world example, how much effort does it take you to add URL args, make it operate like a RESTful resource, change the route that triggers it, add user sessions, address security concerns, template out responses, tweak those templates without touching the code, etc. Some in that list are easy to do via the method above, others are painstaking. What you give up in simplicity, you gain in extensibility and scalability (often, not always). This is true across almost all of the primary non-functional requirements. A good framework is one that lets you build up to a problem, using only the pieces you need and minimizing the time you spend operating with the framework. The mindset in this community naturally gravitates to that solution (function and component combination), but you can find it in other frameworks/languages (Pylons is a great example). Paul On Sep 9, 8:47 am, Mike Meyer wrote: > On Thu, 9 Sep 2010 16:28:48 +0100 > > Edmund Jackson wrote: > > Hi Mike, > > > Could you perhaps present a counter-example of greater simplicity ? > > $ cat - > /usr/local/www/apache22/cgi-bin/hello-world.sh > #!/bin/sh > > echo 'Content-type: text/plain\n' > echo Hello World > ^D > $ chomd 755 /usr/local/www/apache22/cgi-bin/hello-world.sh > > Done. Three lines of source code. 0 lines of framework setup. 1 tool > (sh). Pretty much the same thing works for python, perl, etc. It's > about as robust as can be asked for - that's the nature of > apache. Performance is going to be mediocre at best. That's the > trade-off for simplicity. > > -- > Mike Meyer 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: Simple things should be simple
On Thu, Sep 9, 2010 at 12:05 PM, Mike Meyer wrote: > On Thu, 9 Sep 2010 11:30:51 -0400 > Wilson MacGyver wrote: > >> I'm not sure what your point is. If I want to write a hello world php >> script on a unix >> system, but apache and mod_php weren't setup. I'd first have to install them >> and configure them. > > That simple things should be simple. Setting up a web server - and > associated tools - to the point that you can install applications on > it isn't necessarily simple, so I don't expect it to be simple. On the > other hand, I only have to do that *once*, not once per application > (at least, I hope I don't have to do it once per application!). Am I right in that what you're asking for is something akin to PHP where you upload a jar or *.clj and it "Just Works"(tm) ? I want that too, but this isn't a complaint simply of clojure, it's of web architectures in general. -- http://apgwoz.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
Re: Simple things should be simple
On Thu, Sep 9, 2010 at 12:32 PM, David Nolen wrote: > On Thu, Sep 9, 2010 at 12:22 PM, Mike Meyer > wrote: >> >> Clojure great. No questions about that. WAR files, CLASSPATHs, having >> to wrap *every little command* in it's own script - that's what I'm >> looking at. > > I've already shown that you don't need WAR files. If you really, really hate > the CLASSPATH you should look at cake. It does require ruby, but it let's > you essentially write "instant-on" Clojure shell scripts as well as give you > access to things like the working shell directory if that's the way you want > to work with Clojure. > #!/usr/bin/env cake run > (println "Hello world!") > Other people have felt your pain and have started building solutions. You > can help them out by using those solutions and giving feedback :) Woah. I knew cake did some funky build stuff, but I didn't realize you could make use of it's "global project" like that. The global project seems to amount to something like Python's site-packages or Ruby's gems, right? Just a repo of installed packages for the system? What's the reason that this couldn't be done directly in clojure? (probably not the best place to start this conversation of course) -- http://www.apgwoz.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
Re: Simple things should be simple
On Thu, 9 Sep 2010 12:32:27 -0400 David Nolen wrote: > On Thu, Sep 9, 2010 at 12:22 PM, Mike Meyer < > mwm-keyword-googlegroups.620...@mired.org> wrote: > > > Clojure great. No questions about that. WAR files, CLASSPATHs, having > > to wrap *every little command* in it's own script - that's what I'm > > looking at. > > > I've already shown that you don't need WAR files. If you really, really hate But only if I'm willing to deploy every application in it's own web server. At least as far as I can tell. And you lose the robustness of apache. > the CLASSPATH you should look at cake. It does require ruby, but it let's > you essentially write "instant-on" Clojure shell scripts as well as give you > access to things like the working shell directory if that's the way you want > to work with Clojure. > >#!/usr/bin/env cake run >(println "Hello world!") Um, #!/usr/bin/env clj (println "Hello world!") works fine for me. Better yet, if I know I have a running nailgun, I can do: #!/usr/bin/env clojure (println "Hello world!") (one of these days, I'll patch nailgun to launch itself if it can't find a server) And get much quicker responses. The question now is, how well do all these things interact with each other? 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: Simple things should be simple
On Thu, 9 Sep 2010 17:15:09 +0100 Edmund Jackson wrote: > You assume the presence of a configured web server but not a text editor ? Actually, I did assume a text editor - provided any text editor would do. I chose to use my favorite simple text editor (cat) here. > The only constructive thing I can say is that the set of things that may be > considered simple in the clojure setup above is vastly greater than the > alternative you present. If the cost is a 4 line 'boilerplate' (and I'm > pointedly not going to compare that to /etc/apache/conf.d) I think its a low > price. The difference is that that 4 lines has to be repeated *for every project*. Yeah, /usr/local/etc/apache/conf.d is a lot more complicated. But I only need to do it once, and it works for every application. The thing is, I can write stand-alone servers with Unix tools as well. They're a bit longer than the clojure version, but they still require no external configuration, and just the language processor. I mean, make is a nifty tool for doing builds, but I don't bother with make files for single-file programs or programs that don't need to be built. I'd be much less happy with it if it if I was required to use it for such simple things - which seems to be where the java world is. 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: Simple things should be simple
On Thu, 9 Sep 2010 16:35:15 +0100 Bruce Durling wrote: > Mike, > > If you are happy with cgi and if we posit that clojure is a compiled > language and leiningen is the same as make. The I submit the following > bit of fluff: > > At a prompt: > > $ lein new hw > $ cd hw > $ lein deps > > Then edit project.clj to look as follows: > > (defproject hw "0.0.1" > :description "The smallest hello world that will work." > :dependencies [[org.clojure/clojure "1.2.0"] > [org.clojure/clojure-contrib "1.2.0"]] > :aot [hw.core] > :main hw.core) > > Then edit hw/core.clj as follows: > > (ns hw.core > (:gen-class)) > (defn -main [& args] (println "Hello World.")) > > At a prompt: > > $ lein uberjar > > And create the following shell script hw.sh > > #! /bin/bash > java -jar hw-0.0.1-standalone.jar > > I'm sure you can wire the shell script into your apache. And this > isn't as short as a shell/python/perl script that does print or echo. > > I also fear this is descending into perl golf, but I fancied having a > crack at this anyway on a brain fried day. Yup, and I've seriously thought about something like that. Two issues: my measurements show that using a jar doesn't really improve runtime that much. The other is that, lein works sorta-kinda like make. I like make. But as I just posted, I don't use it for one-file programs or programs that don't need building. That doesn't seem to be possible with lein. 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: Simple things should be simple
On Thu, 9 Sep 2010 09:06:33 -0700 (PDT) Paul deGrandis wrote: > I think the point is missed with this example. > > Given your hello world example, how much effort does it take you to > add URL args, make it operate like a RESTful resource, change the > route that triggers it, add user sessions, address security concerns, > template out responses, tweak those templates without touching the > code, etc. I think you've missed the point of the example. Not everything requires arguments, restful resources, session tracking, etc. If I need those things, I have no problem using a framework that gives them to me. The thing is, if I don't need them, I don't *want* to have to deal things that provide them. Simple things should be simple. Say I'm having a problem with the cpu in a web server overheating. I want to install a simple hack so I can check the temperature on my phone's browser when I'm home (or connected in through the vpn). The shell script/CGI to do this is pretty much identical to the hello world example: #!/bin/sh echo 'Content-type: text/plain\n' sysctl dev.cpu.0.temperature If I didn't have a server installed, it'd be a little bit more complicated, but not a lot. The problem is so simple I don't need to "build up" to it, but the Java world still seems to insist I have that ability - and the complexity that goes with it. Which means that simple things aren't so simple. 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: lisp error system in clojure
On Thu, Sep 9, 2010 at 9:21 AM, Seth wrote: > exact what i want! > Heres a nice link which describes it > > http://pragprog.com/magazines/2009-07/when-things-go-wrong If you actually use any of the continue or continue-with features in real-world code, or build any kind of error hierarchy, please let me know. These features seem very complex for how often they're used so I'd be pleased to find a simpler subset that is at least as useful. --Chouser http://joyofclojure.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
Re: Simple things should be simple
On Thu, 9 Sep 2010 12:23:25 -0400 Andrew Gwozdziewycz wrote: > On Thu, Sep 9, 2010 at 12:05 PM, Mike Meyer > wrote: > > On Thu, 9 Sep 2010 11:30:51 -0400 > > Wilson MacGyver wrote: > > > >> I'm not sure what your point is. If I want to write a hello world php > >> script on a unix > >> system, but apache and mod_php weren't setup. I'd first have to install > >> them > >> and configure them. > > > > That simple things should be simple. Setting up a web server - and > > associated tools - to the point that you can install applications on > > it isn't necessarily simple, so I don't expect it to be simple. On the > > other hand, I only have to do that *once*, not once per application > > (at least, I hope I don't have to do it once per application!). > > Am I right in that what you're asking for is something akin to PHP > where you upload a jar or *.clj and it "Just Works"(tm) ? > > I want that too, but this isn't a complaint simply of clojure, it's of > web architectures in general. Exactly. Well, I'd say "java web architectures", but I'm hoping there is a simple solutions for simple applications out there. 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: Simple things should be simple
On Thu, 9 Sep 2010 09:41:09 -0700 (PDT) Brenton wrote: > Mike, > > Your point has been made, simple things are simple. When you need to > print "hello world" you don't need to bring Clojure into the picture. > You could have given a much simpler example of needing to print "hello > world" on the command line. echo "hello world" is much simpler than > what you would need to do in Clojure. The thing is, I'm evaluating clojure - that's what drags clojure into it. If I wasn't interested in using clojure, I'd never have asked the question. Printing "hello world" is just a simple, well-understood example application. There are *lots* of applications worth putting on the web that aren't much more complicated than that. I chose it to emphasis how much extra work the environment that clojure seems to be inextricably linked with adds. > When faced with any problem to solve, you have to look at the tools > you have available and then determine what the simplest solution will > be. In your case, all of the software you need is already installed, > configured and running. So it's simple. If you gave me a system with > Tomcat installed, configured and running then I could do the exact > same thing. It has nothing to do with Java, it has to do with what you > are given to work with. I thought I *gave* you all those things to work with when I said "not counting the web server and whatever else it needs to be ready to run applications." Could you show me (or point me to an web page showing) how I'd go from a simple .clj script to an application running on Tomcat that's been installed and is ready to run applications? If that's as simple as the apache/cgi example, I'll be very happy. 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: Simple things should be simple
On Thu, Sep 9, 2010 at 10:07 AM, Mike Meyer wrote: > The difference is that that 4 lines has to be repeated *for every > project*. Yeah, /usr/local/etc/apache/conf.d is a lot more > complicated. But I only need to do it once, and it works for every > application. until you need to change it to support a new application's needs, and run the risk of fubaring some or all of the previous applications. -- 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: Simple things should be simple
Mike, While evaluating Clojure, just remember, you don't have use it for everything. When you need something simple, as in your examples, then use cgi. When you need to do something more complex then Clojure can help. You cannot deploy a .clj script on a running Tomcat (yet). When you install Tomcat, you have a ROOT context into which you can place .html and .jsp files and they will be dynamically loaded. This gives you about the same functionality as you would get from php and apache. Even though Clojure doesn't already have what you are looking for it would not be difficult to make it work. For example, you could create a generic web app that would have an embedded REPL as well as the ability to dynamically load code from external files. You would then just need to install Tomcat (which is easy) and drop this war into it. Form then on out you would just create simple .clj scripts and drop them into a directory. You could also connect to the REPL and dynamically add and remove code from the application. This hasn't been done yet because I don't think many people would find it useful. Clojure is new so when you see something missing, build it. That is why all of this other stuff is so simple, someone built it. Brenton On Sep 9, 10:40 am, Mike Meyer wrote: > On Thu, 9 Sep 2010 09:41:09 -0700 (PDT) > > Brenton wrote: > > Mike, > > > Your point has been made, simple things are simple. When you need to > > print "hello world" you don't need to bring Clojure into the picture. > > You could have given a much simpler example of needing to print "hello > > world" on the command line. echo "hello world" is much simpler than > > what you would need to do in Clojure. > > The thing is, I'm evaluating clojure - that's what drags clojure into > it. If I wasn't interested in using clojure, I'd never have asked the > question. Printing "hello world" is just a simple, well-understood > example application. There are *lots* of applications worth putting on > the web that aren't much more complicated than that. I chose it to > emphasis how much extra work the environment that clojure seems to be > inextricably linked with adds. > > > When faced with any problem to solve, you have to look at the tools > > you have available and then determine what the simplest solution will > > be. In your case, all of the software you need is already installed, > > configured and running. So it's simple. If you gave me a system with > > Tomcat installed, configured and running then I could do the exact > > same thing. It has nothing to do with Java, it has to do with what you > > are given to work with. > > I thought I *gave* you all those things to work with when I said "not > counting the web server and whatever else it needs to be ready to run > applications." Could you show me (or point me to an web page showing) > how I'd go from a simple .clj script to an application running on > Tomcat that's been installed and is ready to run applications? If > that's as simple as the apache/cgi example, I'll be very happy. > > -- > Mike Meyer 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: Simple things should be simple
On Thu, 9 Sep 2010 11:00:48 -0700 Raoul Duke wrote: > On Thu, Sep 9, 2010 at 10:07 AM, Mike Meyer > wrote: > > The difference is that that 4 lines has to be repeated *for every > > project*. Yeah, /usr/local/etc/apache/conf.d is a lot more > > complicated. But I only need to do it once, and it works for every > > application. > until you need to change it to support a new application's needs, and > run the risk of fubaring some or all of the previous applications. That problem exists no matter how you do the configuration. But the less per-application configuration you have to do, the less likely it is to happen. 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: Simple things should be simple
On Thu, Sep 9, 2010 at 2:17 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > > run the risk of fubaring some or all of the previous applications. > > That problem exists no matter how you do the configuration. But the > less per-application configuration you have to do, the less likely it > is to happen. > > Also note that you have a certain bias as some us do based on prior experience. I for one do not like Apache at all and will not shed a tear if I never use it again for my own projects. I'd never use bash shell scripting for anything beyond my .profile, much less writing a web app. Note, that if I don't know anything about apache or bash, then you have no valid point. There is nothing simple about installing apache from scratch. There's nothing simple about bash shell scripting. On *some* systems getting these installed is easier, on other systems it's harder. Depending on which tools/languages/databases (and, god forbid, which versions) I'd rather use, it can be much, much, much harder. So enough about simplicity. What we're really talking about here is familiarity. It's takes me no time at all to get a working Clojure web app and running. I have no idea to do the things that you are describing as being simple with apache, httpd.conf, and bash. 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
Re: A difficult Metaphor for Macros (especially for Java people)
The major thing that made me used macros as much as possible when available
in any language was writing assembly code. Not 100 lines projects, 20,000 and
above, mainly made of macro calls.
That's when you realize that you need to use macros to generate instructions
for three reasons:
a) keeping the code size of the system within reasonable limits
b) having the instant ability to change things "under the hood" by altering
your macros instead of erring in the code trying to find the spots where
you must add these new instructions you just find out you urgently need to
make it work.
c) to improve the code readability and maintainability by enforcing common
patterns in the code.
I was blessed to work on DEC environments where the macro processors were
very strong and much more sophisticated than the C preprocessor. Not as
good as Lisp but still very flexible and able to handle complex logic.
For some reason, many common languages of the 70s/80s were missing this
important feature, at least it was not in their respective standards (Cobol,
Fortran, Pascal, ...). I think only Pl1 had some.
One friend of mine in the 80s was working on a HP3000 in Cobol I think
and that implementation had a macro processor but that was an exception
at the time.
My first impression is that they are not enough main macro implementations
widely used these days aside from the C preprocessor which is pretty basic.
The macro feature by itself is probably an strange/alien concept for many
people today.
Learning Lisp by itself is a big chunk so pushing the advantage of Lisp
macros to the forefront is not obvious if the audience cannot compare
with another (good/simple) implementation they understand well.
Luc P.
Laurent PETIT wrote ..
> 2010/9/9 Andrew Gwozdziewycz :
> > On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT
> > wrote:
> >> Hello,
> >>
> >> 2010/9/9 Sean Corfield :
> >>> On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava
> >>> wrote:
> I found the easiest way to introduce macros is just to introduce them
> as small syntactic sugaring. For example, getting rid of the explicit
> (fn [] ...) for macros like (with-open file ...).
> >>>
> >>> Interesting. I don't see any real difference between macros and C
> >>> preprocessor stuff and C++ templates at a conceptual level. I think
> >>> Clojure macros are much cleaner, but essentially they are similar. So
> >>> in the Java world, generics (templates) are not yet widely used
> >>> outside the libraries and maybe that's why Java devs find macros hard
> >>> to comprehend?
> >>
> >> I think that even at the conceptual level, the differences are big:
> >>
> >> a. C/C++ is a "pre-processor". It does a first pass on the code.
> >> Only at the end is the C/C++ compiler invoked. In Lisps, there is
> >> still this "first pass/second pass" thing, but it's at a waay finer
> >> granularity level: the top level form. At the end of the evaluation of
> >> each top level form, a new macro may have been defined and can be
> >> called immediately by the next top level form. So not only is the
> >> "set" of macros not closed in Lisp (and in C/C++, to some extent, it's
> >> also not closed, even if rather limited), but it can be expanded
> >> during the compilation of the "program".
> >
> > Of course the real difference is that in Lisp macros you are working
> > directly on the AST, where in C/C++ macros you're working at the
> > source level. My understanding of the C/C++ preprocessor is that it
> > more or less does a string substitution, which *may* lead to a syntax
> > errors (you often see #define X(y) do { y } while (0); to get around
> > different limitations), or undesired results, not to mention
> > unintended variable capture, etc, etc, etc.
> >
> > The fact that Lisp macros actually operate on the AST means that Lisp
> > macros can make *changes* to the AST (insert things, remove things,
> > rearrange things), and *not* just substitute FOO for BAR. This is a
> > hell of a lot more powerful.
>
> Yeah
>
> --
> 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: Simple things should be simple
On Thu, 9 Sep 2010 11:16:11 -0700 (PDT)
Brenton wrote:
> While evaluating Clojure, just remember, you don't have use it for
> everything. When you need something simple, as in your examples, then
> use cgi. When you need to do something more complex then Clojure can
> help.
The first problem with that is that this stuff seems show up
*everywhere* in Javaland. It's not just web apps, it's pretty much
anything. Second, just because a *problem* is complex and would
benefit from Clojure doesn't mean that the requirements for deployment
are complex and need more than a simple cgi (for example!) would
require. Yes, when the choice is 150 lines of C with 0 lines of config
vs. 20 lines of Clojure with with 10 lines of config, it doesn't look
so bad - but 30% of the work being overhead still sucks.
> You cannot deploy a .clj script on a running Tomcat (yet). When you
> install Tomcat, you have a ROOT context into which you can place .html
> and .jsp files and they will be dynamically loaded. This gives you
> about the same functionality as you would get from php and apache.
I didn't ask "how do I deploy a .clj script on a running Tomcat". I
asked "how do I go from a .clj script to an application running on
Tomcat"? I can't deploy a C program on running Apache server either -
I have to compile and link it first. Not a problem. My 3/0/1 solution
could just as well have been:
$ cat - > hello.c
main() {
puts("Content-type: text/plain\n\nHello world!\n") ;
}
^D
$ cc hello.c
$ cp a.out /usr/local/apache22/cgi-bin/helloworld
Anything even close to that for Tomcat and clj?
> Clojure is new so when you see something missing, build it. That is
> why all of this other stuff is so simple, someone built it.
Good advice. That's what I've been doing so far. On the other hand,
I'd rather spend my time building the things that interest me rather
than reinventing wheels for which I already have adequately round
examples. If my expectations of "adequately round" are much higher
than the communities, then I'll wind up doing to much of the latter
and not enough of the former, and will probably be happier elsewhere.
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: Simple things should be simple
On Sep 9, 8:16 pm, Brenton wrote: > > Even though Clojure doesn't already have what you are looking for it > would not be difficult to make it work. For example, you could create > a generic web app that would have an embedded REPL as well as the > ability to dynamically load code from external files. You would then > just need to install Tomcat (which is easy) and drop this war into it. > Form then on out you would just create simple .clj scripts and drop > them into a directory. You could also connect to the REPL and > dynamically add and remove code from the application. This hasn't been > done yet because I don't think many people would find it useful. > This would be really cool. Especially if, after playing around at the repl, you could call something like: (create-war "example.war") and it would produce a deployable web application using the .clj files you had loaded. Saul -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 11:17 AM, Mike Meyer wrote: > That problem exists no matter how you do the configuration. But the > less per-application configuration you have to do, the less likely it > is to happen. (i might be not-quite-following, but) no, i think the problem i mentioned explicitly doesn't exist in the case of lots of separate config files, one per application, that have duplicated content. sure, it has /another/ problem to replace the one i mentioned, but it is a different thing. in other words: i think there isn't a silver bullet. everything is about context. choose your pain. etc. sincerely. -- 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: Knowing in advance the complexity of count
Inexplicably (counted? "abcd") returns false. On Sep 9, 11:33 am, Sunil S Nandihalli wrote: > actually there is a function called > > counted? > > Sunil. > > On Thu, Sep 9, 2010 at 8:59 PM, Nicolas Oury wrote: > > Thank you very much. > > > Never looked closely at count definition. > > > I assumed it was a forawrd to .count of Counted, which explains my problem. > > > I kind of remembered the O(1) of Counted and get mixed up. > > > Best regards, > > > Nicolas. > > > On Thu, Sep 9, 2010 at 3:50 PM, Meikel Brandmeyer wrote: > > > Hi, > > > > On 9 Sep., 16:45, Nicolas Oury wrote: > > > >> is it a way to do so? > > > > You can check the Counted marker interface for clojure collections. > > > But this won't cover Strings etc. More information here: > > >http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT... > > > > Sincerely > > > Meikel > > > > -- > > > 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 > > > -- > > Sent from an IBM Model M, 15 August 1989. > > > -- > > 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: Simple things should be simple
On Sep 9, 1:40 pm, Mike Meyer wrote: > The thing is, I'm evaluating clojure - that's what drags clojure into > it. What exactly are you evaluating Clojure for? Because unless it's teaching elementary school children, the LOC it takes to deploy a hello world webapp is irrelevant. Luke -- 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: A difficult Metaphor for Macros (especially for Java people)
Interesting discussion! I think about taking some of the topics into separate threads. Will see, I'm a bit under project pressure. Wont tell you the language ;( But, @Luc "pushing the advantage of Lisp macros to the forefront is not obvious if the audience cannot compare with another (good/simple) implementation they understand well." Thats why I want to use a nifty metaphor ;-) @all After reading all your answers and discussion, I ponder whether the words of @ Laurent PETIT "second major difference is that you stay in the same language for writing macros or non macros code in Lisp" are really true. It is, of course, the same for my Java collegues, because its written wit parentheses ;-) But writing lambda forms - and this is what the usual functional programming can be reduced to - and writing macros is very different. Or is it not? (At least to me it is.) (Macros ar tree transformations. I have a hunch that maybe lambda can be seen as a special form of such tree transformations (but I'm a newbee here). If this is true, a new foundation of lisp may be interesting. Not in lambda calculus, but in tree transformation grammars. But that doesnt belong to this thread. Nevertheless, comments are welcome :) Thank you all, and kind regards, alux On 9 Sep., 20:40, lprefonta...@softaddicts.ca wrote: > The major thing that made me used macros as much as possible when available > in any language was writing assembly code. Not 100 lines projects, 20,000 and > above, mainly made of macro calls. > > That's when you realize that you need to use macros to generate instructions > for three reasons: > > a) keeping the code size of the system within reasonable limits > > b) having the instant ability to change things "under the hood" by altering > your macros instead of erring in the code trying to find the spots where > you must add these new instructions you just find out you urgently need to > make it work. > > c) to improve the code readability and maintainability by enforcing common > patterns in the code. > > I was blessed to work on DEC environments where the macro processors were > very strong and much more sophisticated than the C preprocessor. Not as > good as Lisp but still very flexible and able to handle complex logic. > > For some reason, many common languages of the 70s/80s were missing this > important feature, at least it was not in their respective standards (Cobol, > Fortran, Pascal, ...). I think only Pl1 had some. > > One friend of mine in the 80s was working on a HP3000 in Cobol I think > and that implementation had a macro processor but that was an exception > at the time. > > My first impression is that they are not enough main macro implementations > widely used these days aside from the C preprocessor which is pretty basic. > > The macro feature by itself is probably an strange/alien concept for many > people today. > > Learning Lisp by itself is a big chunk so pushing the advantage of Lisp > macros to the forefront is not obvious if the audience cannot compare > with another (good/simple) implementation they understand well. > > Luc P. > > Laurent PETIT wrote .. > > > 2010/9/9 Andrew Gwozdziewycz : > > > On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT > > > wrote: > > >> Hello, > > > >> 2010/9/9 Sean Corfield : > > >>> On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava > > >>> wrote: > > I found the easiest way to introduce macros is just to introduce them > > as small syntactic sugaring. For example, getting rid of the explicit > > (fn [] ...) for macros like (with-open file ...). > > > >>> Interesting. I don't see any real difference between macros and C > > >>> preprocessor stuff and C++ templates at a conceptual level. I think > > >>> Clojure macros are much cleaner, but essentially they are similar. So > > >>> in the Java world, generics (templates) are not yet widely used > > >>> outside the libraries and maybe that's why Java devs find macros hard > > >>> to comprehend? > > > >> I think that even at the conceptual level, the differences are big: > > > >> a. C/C++ is a "pre-processor". It does a first pass on the code. > > >> Only at the end is the C/C++ compiler invoked. In Lisps, there is > > >> still this "first pass/second pass" thing, but it's at a waay finer > > >> granularity level: the top level form. At the end of the evaluation of > > >> each top level form, a new macro may have been defined and can be > > >> called immediately by the next top level form. So not only is the > > >> "set" of macros not closed in Lisp (and in C/C++, to some extent, it's > > >> also not closed, even if rather limited), but it can be expanded > > >> during the compilation of the "program". > > > > Of course the real difference is that in Lisp macros you are working > > > directly on the AST, where in C/C++ macros you're working at the > > > source level. My understanding of the C/C++ preprocessor is that it > > > more or less does a string substitution, which *may* lead to a
Re: Simple things should be simple
On Thu, 9 Sep 2010 14:27:48 -0400 David Nolen wrote: > On Thu, Sep 9, 2010 at 2:17 PM, Mike Meyer < > mwm-keyword-googlegroups.620...@mired.org> wrote: > > > run the risk of fubaring some or all of the previous applications. > > That problem exists no matter how you do the configuration. But the > > less per-application configuration you have to do, the less likely it > > is to happen. > Also note that you have a certain bias as some us do based on prior > experience. I for one do not like Apache at all and will not shed a tear if > I never use it again for my own projects. I'd never use bash shell scripting > for anything beyond my .profile, much less writing a web app. Which is why I started with "I can do it with 0 configuration with my favorite tools installed, how close can javaland tools come to that?" It wasn't until someone asked me to demonstrate that apache and sh (god save us from bash) entered into it. Of course, the choice of apache and sh is irrelevant. I could have used pretty much any Unix web server, and pretty much any programming language which plays well in that environment, with about as much effort. There might have been some trivial changes to adopt things to some of them (compiled vs. interpreted, .cgi suffix vs cgi-bin directory, etc.), but the point remains that the underlying philosophy of this ecosystem means that simple things are simple. > Note, that if I don't know anything about apache or bash, then you have no > valid point. There is nothing simple about installing apache from scratch. > There's nothing simple about bash shell scripting. On *some* systems getting > these installed is easier, on other systems it's harder. Depending on which > tools/languages/databases (and, god forbid, which versions) I'd rather use, > it can be much, much, much harder. Which is why I *explicitly* asked people to show me how to do this using *their favorite tools*. > So enough about simplicity. What we're really talking about here is > familiarity. It's takes me no time at all to get a working Clojure web app > and running. I have no idea to do the things that you are describing as > being simple with apache, httpd.conf, and bash. No, it's not about familiarity, it's about boilerplate. You provided an example that was much better than anything I expected to find. I'd still like to see what it takes to use that to create something I can deploy on Tomcat or GlassFish or whatever, than as a standalone server. Having to run standalone servers for every little applcation - isn't simple 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: Simple things should be simple
On Thu, 9 Sep 2010 11:48:36 -0700 (PDT) Saul Hazledine wrote: > On Sep 9, 8:16 pm, Brenton wrote: > > > > Even though Clojure doesn't already have what you are looking for it > > would not be difficult to make it work. For example, you could create > > a generic web app that would have an embedded REPL as well as the > > ability to dynamically load code from external files. You would then > > just need to install Tomcat (which is easy) and drop this war into it. > > Form then on out you would just create simple .clj scripts and drop > > them into a directory. You could also connect to the REPL and > > dynamically add and remove code from the application. This hasn't been > > done yet because I don't think many people would find it useful. > > This would be really cool. Especially if, after playing around at the > repl, you could call something like: > (create-war "example.war") > and it would produce a deployable web application using the .clj files > you had loaded. Gee, that sounds like the web apps I was building a decade ago, except it was standalone. It pretty much loaded all the code in the deployment directory, let you telnet into a repl to poke around in the guts of the system, including reloading modules, adding new ones, resetting things. Unfortunately, times have changed, and I'm looking for better tools. Clojure definitely a better language 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: clojure-contrib master now in submodules
On Aug 20, 7:22 am, Stuart Sierra wrote: > If you want to use ALL contrib libraries, add a dependency on group > "org.clojure.contrib", artifact "complete", version "1.3.0-SNAPSHOT". > This meta-library depends on all other contrib libraries. This doesn't work because as was pointed out on IRC today, there's currently a "bin" classifier. You have to use: [org.clojure.contrib/complete "1.3.0-SNAPSHOT" :classifier "bin"] --Brian -- 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: matching with wild-cards in clojure multi-methods
On 9 September 2010 07:31, Meikel Brandmeyer wrote: > derive works with non-qualified keywords, but the contract disallows > that: Apparently the contract given in the docstring is being enforced in derive's 2-arg definition, but the "must be namespaced" parts of the assertions are missing from the 3-arg definition (the one which takes a custom hierarchy). This difference is quite unexpected. Could this be a bug? -- 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: Simple things should be simple
just skimming the thread all I see is mention of war files, which, well, who cares? just get ring and the ring jetty adapter, you don't even after to presume the existence of an installed webserver or servlet container. http://github.com/hiredman/place-for-things is something I have been playing with that uses ring and jetty. On Thu, Sep 9, 2010 at 12:33 PM, Mike Meyer wrote: > On Thu, 9 Sep 2010 11:48:36 -0700 (PDT) > Saul Hazledine wrote: > >> On Sep 9, 8:16 pm, Brenton wrote: >> > >> > Even though Clojure doesn't already have what you are looking for it >> > would not be difficult to make it work. For example, you could create >> > a generic web app that would have an embedded REPL as well as the >> > ability to dynamically load code from external files. You would then >> > just need to install Tomcat (which is easy) and drop this war into it. >> > Form then on out you would just create simple .clj scripts and drop >> > them into a directory. You could also connect to the REPL and >> > dynamically add and remove code from the application. This hasn't been >> > done yet because I don't think many people would find it useful. >> >> This would be really cool. Especially if, after playing around at the >> repl, you could call something like: >> (create-war "example.war") >> and it would produce a deployable web application using the .clj files >> you had loaded. > > Gee, that sounds like the web apps I was building a decade ago, except > it was standalone. It pretty much loaded all the code in the > deployment directory, let you telnet into a repl to poke around in the > guts of the system, including reloading modules, adding new ones, > resetting things. > > Unfortunately, times have changed, and I'm looking for better > tools. Clojure definitely a better language > > -- > Mike Meyer 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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: Simple things should be simple
On Thu, 9 Sep 2010 12:04:34 -0700 (PDT) Luke Renn wrote: > On Sep 9, 1:40 pm, Mike Meyer 620...@mired.org> wrote: > > The thing is, I'm evaluating clojure - that's what drags clojure into > > it. > What exactly are you evaluating Clojure for? Because unless it's > teaching elementary school children, the LOC it takes to deploy a > hello world webapp is irrelevant. Here I thought I could save time by choosing a nice, simple example application that everyone would understand, rather than spending a lot of time explaining (or abstracting out) irrelevant details of some real-world application before asking the question about the overhead required to deploy java web apps. Instead, I seem to be spending a lot more time explaining what "example" means. Ok, lets use a different example. I'm going to deploy a web app. Let's call it SuperDuper. It's going to take two arguments. The first argument is used to locate, lock and load a collection of data. If the data is already locked, it just spits out an error. If the data isn't locked, it uses the second argument to process the data IN A WAY FOR WHICH CLOJURE IS IDEAL, possibly changing it, and finally spits out it's a result. I expect the initial version to have to handle no more than a few hundred requests a day while we do usability testing, and decide if we want do any further development. Now, given that I have a clj file that implements (SuperDuper datalocation processingdirective), how much manure do I have to spread around it to get it to grow into a functioning web app deployed on your favorite web server? The key word is "on" - we may want to run more multiple variants, and don't want to have to deal with multiple servers. Further, if this works, we'll be working on other, similar, applications. All of which means we run one server and put applications on it, rather than putting every application on it's own server. If I wrote this in any language that plays well in the Unix environment (which lets out a lot of LISP-like languages), on most any reasonable Unix server, the answer is "Create an executable and name it properly." Java-based languages seem to have trouble with the first step (which is why I'm willing to consider *your* favorite server), much less the second one. FWIW, most of the languages I use can do the "run our own private server" hack. They usually take a little more overhead code than Ring. On the other hand, writing a rock-stupid http server that just does sockets and query parsing doesn't take a lot more overhead than Ring. But for reasons previously stated, this case is uninteresting. 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
Using a keyword as object get method
I'm using thrift-generated Java objects heavily inside hadoop and it would be nice to access object properties using keyword notation instead of .getPropertyX. At platform speed of course. Searching the list shows someone else interested in the same thing but no answer. http://groups.google.com/group/clojure/browse_thread/thread/15cf030cab0fc1/38d580b4492d8ef1 Any suggestions? -- 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: Simple things should be simple
On 9 September 2010 19:16, Brenton wrote: > Mike, > > While evaluating Clojure, just remember, you don't have use it for > everything. When you need something simple, as in your examples, then > use cgi. When you need to do something more complex then Clojure can > help. > > You cannot deploy a .clj script on a running Tomcat (yet). When you > install Tomcat, you have a ROOT context into which you can place .html > and .jsp files and they will be dynamically loaded. This gives you > about the same functionality as you would get from php and apache. > > Even though Clojure doesn't already have what you are looking for it > would not be difficult to make it work. For example, you could create > a generic web app that would have an embedded REPL as well as the > ability to dynamically load code from external files. You would then > just need to install Tomcat (which is easy) and drop this war into it. > Form then on out you would just create simple .clj scripts and drop > them into a directory. > You could also connect to the REPL and > dynamically add and remove code from the application. Or use something like jnotify to notify your application that the directory has been changed and have it automagically load/reload the code. I did this once a few months back - if I changed my .clj file or added a new one, the app detected it and loaded it. > This hasn't been > done yet because I don't think many people would find it useful. > > Clojure is new so when you see something missing, build it. That is > why all of this other stuff is so simple, someone built it. > > Brenton > > > On Sep 9, 10:40 am, Mike Meyer 620...@mired.org> wrote: > > On Thu, 9 Sep 2010 09:41:09 -0700 (PDT) > > > > Brenton wrote: > > > Mike, > > > > > Your point has been made, simple things are simple. When you need to > > > print "hello world" you don't need to bring Clojure into the picture. > > > You could have given a much simpler example of needing to print "hello > > > world" on the command line. echo "hello world" is much simpler than > > > what you would need to do in Clojure. > > > > The thing is, I'm evaluating clojure - that's what drags clojure into > > it. If I wasn't interested in using clojure, I'd never have asked the > > question. Printing "hello world" is just a simple, well-understood > > example application. There are *lots* of applications worth putting on > > the web that aren't much more complicated than that. I chose it to > > emphasis how much extra work the environment that clojure seems to be > > inextricably linked with adds. > > > > > When faced with any problem to solve, you have to look at the tools > > > you have available and then determine what the simplest solution will > > > be. In your case, all of the software you need is already installed, > > > configured and running. So it's simple. If you gave me a system with > > > Tomcat installed, configured and running then I could do the exact > > > same thing. It has nothing to do with Java, it has to do with what you > > > are given to work with. > > > > I thought I *gave* you all those things to work with when I said "not > > counting the web server and whatever else it needs to be ready to run > > applications." Could you show me (or point me to an web page showing) > > how I'd go from a simple .clj script to an application running on > > Tomcat that's been installed and is ready to run applications? If > > that's as simple as the apache/cgi example, I'll be very happy. > > > > > -- > > Mike Meyer > 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 > -- Daniel Kersten. Leveraging dynamic paradigms since the synergies of 1985. -- 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
Improved stack traces
People frequently complain about Clojure's stack traces, and there are now some enhancements in the master branch. In particular, there is a new function in clojure.repl, pst, which prints a nicer stack trace of the most recent (or a supplied) exception. It also has depth control. pst is automatically available in the standard REPL. The single-line initial messages should also be better. Note as always that if you have a compilation/syntax error, the stack can of course have nothing on it but the compiler logic itself. But the file and line number of the code being compiled will, if available, be in the single-line report. Feedback welcome, Rich -- 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: Simple things should be simple
On Sep 9, 4:13 pm, Mike Meyer wrote: > Here I thought I could save time by choosing a nice, simple example > application that everyone would understand, rather than spending a lot > of time explaining (or abstracting out) irrelevant details of some > real-world application before asking the question about the overhead > required to deploy java web apps. The subject of the thread is Simple Things Should Be Simple. Others in this thread have done a good job attempting to explain that they are in fact simple so I won't continue. Perhaps you should play around with ring and/or Compojure a bit and learn yourself. This is something you would have to do for any serious evaluation anyway. I will answer your specific question about deploying applications. While creating a war file may involve some of what you conceive to be boilerplate, it does so to simplify deployment of multiple applications to a single server; which is exactly what you're now asking about. Download jetty, copy a war into the webapps directory and start the server. Done. Don't like Jetty for some reason? Download tomcat, copy the war to the webapps directory, start server. Done. Want another app in that server, just copy the war into webapps. It's the same with the scripts really. You think project.clj, lein, a main class and running java -jar myapp.jar is silly when you can just gcc myapp.c and run it with myapp. Sure, but that only works on a single platform. The java -jar will work anywhere. Like I said, you might think some things are boilerplate or unnecessary, but they're done that way to provide benefits that are beyond simplicity. Best of luck to you. -- 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: Simple things should be simple
On Sep 9, 2:46 pm, Mike Meyer wrote:
> I have to compile and link it first. Not a problem. My 3/0/1 solution
> could just as well have been:
>
> $ cat - > hello.c
> main() {
> puts("Content-type: text/plain\n\nHello world!\n") ;
> }
> ^D
> $ cc hello.c
> $ cp a.out /usr/local/apache22/cgi-bin/helloworld
>
> Anything even close to that for Tomcat and clj?
Again, I'll just say, why is this relevant to a serious evaluation?
How simple is it for you to add a dependency to 10 3rd party libraries
and link against them? What if you want it to run on linux, windows,
and OSX? What you call "boilerplate" isn't boilerplate. It's there
to make things that actually matter simple.
Luke
--
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: Improved stack traces
I assume I'm just clueless here, but the last commit I see at http://github.com/richhickey/clojure is one from Stuart Halloway in June. Where do I find this so I can try it out? Or, what version do I have to tell leiningen I depend on - 1.2.0-snapshot, 1.3.0-snapshot, or something like that? On Sep 9, 1:58 pm, Rich Hickey wrote: > People frequently complain about Clojure's stack traces, and there are > now some enhancements in the master branch. In particular, there is a > new function in clojure.repl, pst, which prints a nicer stack trace of > the most recent (or a supplied) exception. It also has depth control. > pst is automatically available in the standard REPL. > > The single-line initial messages should also be better. > > Note as always that if you have a compilation/syntax error, the stack > can of course have nothing on it but the compiler logic itself. But > the file and line number of the code being compiled will, if > available, be in the single-line report. > > Feedback welcome, > > Rich -- 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: Improved stack traces
http://github.com/clojure/clojure -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
drop-while and (pred item) returns nil?
Hi, According to drop-while doc, (pred item) will return nil. It struck me as I thought the form would only return a boolean. Is the doc correct? What would be an example? user=> (doc drop-while) - clojure.core/drop-while ([pred coll]) Returns a lazy sequence of the items in coll starting from the first item for which (pred item) returns nil. Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://jaceklaskowski.pl -- 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: Simple things should be simple
On Sep 9, 2010, at 3:04 PM, Luke Renn wrote: > What exactly are you evaluating Clojure for? Because unless it's > teaching elementary school children, the LOC it takes to deploy a > hello world webapp is irrelevant. > > Luke >From the sidelines -- because I know little about web apps per se in any >environment -- Mike's original question resonated with me and I want to second >his call for making simple things simple. Clojure makes many important things >simple, particularly within the Clojure code itself, but for someone new to >the java world some of trappings are really not simple (yet!) and I think it's >probably hard for those of you with more experience and all of the tools >installed and boilerplate memorized to have perspective on this. I'm not teaching elementary school but I am teaching college students with experience in a variety of languages (some know some java but some don't) and myself (some experience in a lot of languages, but the deepest experience in Lisp), and both they and I aim to do significant work in Clojure (and I think I already am, even though I'm still pretty clueless about most of the java-world stuff that gets discussed here). More than once I've seen people write that something is simple here and then found that the explanation required more steps than I would have guessed and tools that I never heard of. It's quite possible that these methods/tools are excellent and the best way to do the things eventually, but providing really simple ways to do the really simple things can really help in a lot of contexts, especially (but not only) for newcomers who may eventually enrich the community in many ways. To take one non-webapp example regarding basic tooling, it seems like Leiningen is one thing that can make many things relatively simple but since I've settled on Eclipse/CCW as my development/teaching environment to keep other things simple, and since I don't yet have any idea how to use Leiningen from within Eclipse/CCW, a lot of things aren't yet simple for me. I've posted about this on the CCW list and I expect that will lead to good things -- I've found the CCW folks to be extremely helpful so far -- but right now a lot of things aren't simple in my environment. One of my favorite examples of making the simple stuff simple is Processing (processing.org), which can be downloaded and installed with a single click, and allows you to make an applet with the graphical equivalent of HelloWorld with one line of code, entered in an intuitive IDE with a few very nice features like quick access to documentation, and a single click on an "Export" button. Then move the resulting folder to your server and your applet is live on the web. Add a little more code and you can quickly scale up to rich, interactive, and beautiful applets. If you want more you can add arbitrary java code and do many more things, although there are some limits imposed by the applet target and I guess this isn't a fully general programming platform. But I think it's a superb example of making the simple stuff simple while also allowing those who want to do more complicated things to do so. And it contrasts starkly with my experience with Clojure which, as much as I love the language itself (and I really really do), has had me fighting with classpaths, directory structures, emacs configs, tools that don't talk to each other, etc. to do a variety of things that seemed like they should have been simple. I know that Clojure and its associated tools are works in progress and I'm not complaining that things aren't instantly perfect. But I want to stress that it really is a very good thing to make the simple stuff really simple, and to remind people with more expertise that they themselves are not in a very good position to judge what's simple (because they are polluted by their expertise). -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.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
Re: Standalone 1.2 contrib
Yes, it's in the ZIP file, distributed through http://clojure.org/downloads It's in the ZIP file at target/clojure-contrib-1.2.0.jar You can also download it directly at http://build.clojure.org/releases/org/clojure/clojure-contrib/1.2.0/clojure-contrib-1.2.0.jar Do we need a direct link to the JAR on the download page? That's easy enough. -S On Sep 8, 3:21 pm, Sean Devlin wrote: > Is there a monolithic standalone contrib jar out there? A download & > forget type of thing? -- 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-contrib master now in submodules
Can you clarify? Maven-aware build tools (e.g. Leiningen) should not be trying to downlaod the "clojure-contrib:complete" JAR file. Instead, referencing the "complete" project as a dependency should transitively give you all its dependencies. Does that not work? -S On Sep 9, 3:47 pm, Brian Carper wrote: > On Aug 20, 7:22 am, Stuart Sierra wrote: > > > If you want to use ALL contrib libraries, add a dependency on group > > "org.clojure.contrib", artifact "complete", version "1.3.0-SNAPSHOT". > > This meta-library depends on all other contrib libraries. > > This doesn't work because as was pointed out on IRC today, there's > currently a "bin" classifier. You have to use: > > [org.clojure.contrib/complete "1.3.0-SNAPSHOT" :classifier "bin"] > > --Brian -- 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: Simple things should be simple
On Thu, Sep 9, 2010 at 5:53 PM, Lee Spector wrote: > > One of my favorite examples of making the simple stuff simple is Processing > (processing.org), which can be downloaded and installed with a single > click, and allows you to make an applet with the graphical equivalent of > HelloWorld with one line of code, entered in an intuitive IDE with a few > very nice features like quick access to documentation, and a single click on > an "Export" button. I started using Processing since version 22 (around 2003/4). Let's just say... that it takes a lot of time and external contribution to reach the level of documentation, stability and cross platform reliability that Processing now has. 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
Re: Simple things should be simple
On Thu, 9 Sep 2010 14:11:44 -0700 (PDT)
Luke Renn wrote:
> On Sep 9, 2:46 pm, Mike Meyer 620...@mired.org> wrote:
> > I have to compile and link it first. Not a problem. My 3/0/1 solution
> > could just as well have been:
> >
> > $ cat - > hello.c
> > main() {
> > puts("Content-type: text/plain\n\nHello world!\n") ;
> > }
> > ^D
> > $ cc hello.c
> > $ cp a.out /usr/local/apache22/cgi-bin/helloworld
> >
> > Anything even close to that for Tomcat and clj?
>
> Again, I'll just say, why is this relevant to a serious evaluation?
> How simple is it for you to add a dependency to 10 3rd party libraries
> and link against them? What if you want it to run on linux, windows,
> and OSX?
Well, the original version *would* work on all three of those
systems. And I can do that in something more suitable to large-scale
programming as well - like I said, pretty much any language that plays
well on Unix, whether it's interpreted, compiled or both. And if I
needed to link in extra dependencies, I'd use a make file, or CPAN, or
whatever was appropriate.
The thing is, the software tool/unix philosophy of "simple things
should be simple" means that I don't *have* to have a make file (or
whatever) for simple things. The Java philosophy is apparently "we'll
make sure there are no simple things".
> What you call "boilerplate" isn't boilerplate. It's there
> to make things that actually matter simple.
Doesn't matter - it keeps simple things from being simple, which is
what I'm asking about.
Of course, you're only half right - a lot of it *is* boilerplate, in
two different senses of the word. Look at just *one* example of the
*four* files I have to create to create a war file: web.xml.
Six lines right off the top that are going to be the same in *every*
application. That's boilerplate, as surely as "main() {" in my example
is. It's just that there's twice as much text there as there is in the
*entire system* above. I have to repeat the app name in three places
in the file: more boilerplate, of a more insidious nature. Yeah, if
you want to get fancy, those may wind up being different. I don't want
to get fancy, I want something simple, so why not provide a default
that works for the simple cases? The way it is now is like C++
requiring that I type variable types twice to create a variable. I'm
sure people who are used to that kind of crap consider it simple too.
Pretty much everything else in the deployment process is equally bad:
I have to tell the system things that should be the obvious defaults,
many of those defaults being things I've already told the system.
Sure, there may eventually be a leningen module to deal with all
this. And yeah, compared to what it shelters you from, leningen is a
great tool, and makes life a lot easier. But the fact that you *need*
something like leningen is as much an indication of the failure of the
underlying system as the fact that someone wrote cdecl is an
indication of the failure of C's type declaration syntax.
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: clojure-contrib master now in submodules
On Sep 9, 3:13 pm, Stuart Sierra wrote: > Can you clarify? Maven-aware build tools (e.g. Leiningen) should not > be trying to downlaod the "clojure-contrib:complete" JAR file. > Instead, referencing the "complete" project as a dependency should > transitively give you all its dependencies. Does that not work? > > -S Nope. When I use [org.clojure.contrib/complete "1.3.0-SNAPSHOT"] without :classifier "bin", Maven dies because it can't find the "complete" JAR file. Like this: http://gist.github.com/572306 When I specify [... :classifier "bin"], it downloads all 50+ contrib JAR files, as well as "complete-1.3.0-SNAPSHOT-bin.jar". --Brian -- 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: drop-while and (pred item) returns nil?
Boolean seems to work: user=> (drop-while #(< % 4) (range 10)) (4 5 6 7 8 9) user=> On Sep 9, 2:51 pm, Jacek Laskowski wrote: > Hi, > > According to drop-while doc, (pred item) will return nil. It struck me > as I thought the form would only return a boolean. Is the doc correct? > What would be an example? > > user=> (doc drop-while) > - > clojure.core/drop-while > ([pred coll]) > Returns a lazy sequence of the items in coll starting from the first > item for which (pred item) returns nil. > > Jacek > > -- > Jacek Laskowski > Notatnik Projektanta Java EE -http://jaceklaskowski.pl -- 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: Simple things should be simple
no this discussion is going to be ... won't say it. Quiz: - is your solution functional (regarding the requirements= - is your solution scallable? (groing large or running plattformindependent?) - is your solution easily maintainable (in the sense of mutating it some days to get complex and have 10 LOC) - is it very easily testable Sure you stated out "for simple things". now have java installed, or .net (i'm actually a .net guy). I could complain about this solution not running on windows .. I do not. You have the choice, you make the move. Why should clojure fit into your micro world of doing administrativ scripting? Being a dev for 13 years I really don't like system that don't fullfill my questions. I was a maintainer of a system containing of 8.000.000 LOCs (were I was responsible for round about 300.000) I can tell you tons of horrible stories. Now how is this realted to your question? The right tools for the right job. I won't use any more tools, that don't fullfill my 4 questions. Why, you could ask? because of the experience going the hard way over and over again. Because some businesspeople told me to not use technologie x. Because they don't trust my expertise. In your unix consulting world this maybe the right choice. So the simplest possible hast nothing todo with the right choice, from my point of view. Its not only a matter of having the power at your fingertipps (in only using 2 lines of code). There are even dynamic vs. static language wars. There's no winner, there's no looser. It depends. Be open minded and use the right tool for the right job an don't complain about technologie x or y. Have you ever used .NET or Mono? Yes, No, Why? Im not biased to *nix (actually i'm running a win7 dev machin, because my job requires it) -- 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
