And for comparison at World Singles:

Clojure source 101 files 17952 total loc,
    1321 fns, 666 of which are private,
    203 vars, 8 macros, 29 atoms
Clojure tests 43 files 3790 total loc
Clojure WebDriver tests 14 files 560 total loc

(includes comments / whitespace etc - this is just the output of a simple 
script we run every week to track where we are on migration from our legacy 
code base and growth of our Clojure code)

The atoms are nearly all just caches. We're moving away from private functions.

Sean

On Apr 9, 2014, at 1:17 AM, Colin Yates <colin.ya...@gmail.com> wrote:

> Gah - 5547 production, 2600 of tests.  A lot of that discrepancy is down to 
> the very extensive documentation that https://github.com/gdeer81/marginalia 
> allows you to write.
> 
> Please forgive any other mistakes, working on less than an hours sleep due to 
> my lovely kids.
> 
> On Wednesday, 9 April 2014 09:14:38 UTC+1, Colin Yates wrote:
> Hello back!
> 
> We are using Clojure on the JVM as the implementation language for a platform 
> that will underpin our applications for the next decade.  It is relatively 
> new and so far we have implemented the analysis module which is essentially a 
> generic charting engine.  
> 
> So far we have 5547 lines of production code (including comments) and 2600 
> lines of production code (including comments).
> 
> That doesn't sound like much but I can tell you it is replacing a similar, 
> but slightly smaller in scope analysis module written in Java which was 
> around 40K lines of production code.
> 
> Our architecture is Clojure on the back end exporting a number of JSON end 
> points.  It is backed by MS SQL using the fantastic 
> https://github.com/jkk/honeysql library.
> 
> For me, it is a dream coming from Java (and to a much lesser extent Scala), 
> but it does have its costs.  Moving from an OO world to an FP world isn't 
> easy, particularly in the shapes your solutions end up with.  I am also 
> feeling the pain of not having types - everything is a sequence.  This is a 
> joy but it also means a whole bunch of information (i.e. type information) is 
> lost.  
> 
> One of the wins in OO languages is the many number of places to hang semantic 
> information - the name of the class, the structure of the class, the names of 
> the methods etc.  I also find many more intermediary variables in OO where as 
> in Clojure it seems more idiomatic to have pipelines of transformation.  I am 
> feeling the lost of static types as I refactor APIs particularly.
> 
> This is undoubtedly my failing not Clojure's and I just need to absorb more 
> good FP paradigms.  Would I give up my emacs and Clojure and paredit 
> combination?  Not a chance :).
> 
> Col
> 
> On Tuesday, 8 April 2014 20:23:06 UTC+1, Anthony Ortiz wrote:
> Hello world!
> 
> I'm a C# developer who recently went to an interview at a major bank here in 
> NYC and found that they've been using Clojure for their business logic for 
> over a year already and that got me curious, so I find myself on unfamiliar 
> territory learning how to program in a functional language. So far so good, 
> Moxley Stratton's online tutorial combined with Try Clojure (the online 
> interpreter) has been very helpful (kudos to you guys!) and I'm now going 
> through the book 'Programming Clojure'. So far I've seen a lot of 
> utility/academic examples such as fibonacci but little in the way of an 
> actual real-world example of a top-to-bottom desktop application built using 
> Clojure on either the JVM or CLR, something simple that would demonstrate how 
> Clojure fits into the event-driven model on the client-side behind, let's 
> say, WPF, and how it would interact with more Clojure on the service-side 
> via, let's say, WCF. Does anyone know of an example they can direct me to?
> 
> Many thanks!
> 
> Anthony


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to