@hpincket aye. So `*` in #clojure won't take you through the bignum barrier, you need `*'`. And recursion is problematic in Clojure because of the limitations of the JVM stack.

But that's a perfectly good algorithm for factorial, for small values of `n`.

@Regenaxer @borkdude @vindarel Thanks! Right, so my comparable in-REPL times for iterative factorial 1000 are

#PicoLisp: (bench (apply * (range 1 1000)))
0.000 sec
#Clojure: user=> (time (apply *' (range 1 1000)))
"Elapsed time: 2.428199 msecs"
#SBCL: CL-USER[1]: (time (apply #'* (alexandria:iota 1000 :step 1)))
Evaluation took:
0.000 seconds of real time
0.000015 seconds of total run time (0.000000 user, 0.000015 system)
100.00% CPU
45,990 processor cycles
0 bytes consed

@vindarel That's true. The startup time issue is particularly harsh on #clojure, and @borkdude's #Babashka would probably do a lot better.

But (a) this is very rough timing, and (b) startup time is some sort of proxy for the compactness of the runtime system; and
(c) the thing that's still astounding me is that #PicoLisp is (sort-of) an interpreter, while all the others execute compiled code, so bloody should be faster!

@screwtape Other. Write on #Cryogen, @yogthos' excellent #Clojure static site generator/blogging engine.

It is a bit geeky -- you have to be comfortable with a command line. I keep thinking about writing a little GUI launcher for it to make it easier for my less geeky friends, but I haven't got round to that yet.

http://cryogenweb.org/

@nsrahmad @mapcar @praetor I very much dislike special cases. A language should be clean. It's also not English and shouldn't pretend to be. But #Clojure has a similar noise keyword, `:else`, for `cond`, and while `true` still works, of course, Clojure's static analyser, whines if you use it.

Furthermore the JVM stack is horrible, and Clojure's 'simplified' syntax for arg lists, cond statements, let bindings and case is... sub-optimal, in my opinion.

So you takes your pick.

@mapcar @nsrahmad @praetor #Clojure. It, too, has many flaws; but I think it's the best Lisp in widespread use now.

@nsrahmad @ksaj @praetor why use `t`?

Because my training is in logic, and `t` is an expression which is always true;
Because I've been using it for the past 42 years and see no reason to change;
Because it works in more or less any dialect of #Lisp, not just "Common" Lisp (but note that #Scheme uses `else` rather than `otherwise`, and Portable Standard Lisp, just to keep you on your toes, uses `NIL`, while #Clojure uses nothing at all)!

In short, because.

@Ardubal @mdhughes @amoroso I'm going to say this here: Common #Lisp bracketing syntax for let bindings, cond clauses and arg lists is **so much** clearer and more readable than #Clojure's 'simplified' syntax.

Rare indeed it is that I admit that Common Lisp got *anything* right, but this is right (and on this Clojure is just plain wrong).

@Ardubal @mdhughes @amoroso anything you're referring to inside a function should either be a parameter or a local binding, so namespaced variable names aren't particularly relevant. Namespaced keywords in #Clojure make sense because they are in effect functors onto maps, but namespaced variables are *almost* a code smell.