Our codebase is 6.8k kloc of production code, 4k of test code. We use
emacs, slime+swank to develop.
The editor is great, REPL is great. But lacking debuging and
refactoring support is a pain.
On Jul 3, 9:26 am, Mark Engelberg mark.engelb...@gmail.com wrote:
Ideally, I was hoping to start a
On Thu, Jul 7, 2011 at 2:45 AM, Feng Shen shen...@gmail.com wrote:
But lacking debuging and
refactoring support is a pain.
In case you're not familiar with these (not saying they're full-featured):
https://github.com/pallet/ritz
http://www.youtube.com/watch?v=d_L51ID36w4
On Tue, Jul 5, 2011 at 2:58 PM, David Nolen dnolen.li...@gmail.com wrote:
On Tue, Jul 5, 2011 at 12:59 PM, Ken Wesson kwess...@gmail.com wrote:
On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
In general, I have found that namespaces should be larger than my
Don't know if it counts as large, but I'm running a 20,000+ LOC
project for a 100%-Clojure web app at www.wusoup.com.
My 2c: I'm not an experienced developer by any stretch of the
imagination; this is something I'm working on completely alone, and
yet I've so far found the whole thing incredibly
On Wed, Jul 6, 2011 at 3:49 AM, Peter Taoussanis ptaoussa...@gmail.com wrote:
Can't really comment on how easily Clojure works for large groups of
developers as such. The flexibility thing might start losing it's
charm when you have 10 different coding styles competing with one
another under
What you say especially resonates with me regarding the 'ease of use' wrt
hammering code in a highly iterative/productive way, and I have approached a
number of 'enterprise' size solutions in exactly that way with extremely
robust results (IMO of course :-)).
On 6 July 2011 08:49, Peter
On Wed, Jul 6, 2011 at 3:18 AM, Johan Gardner jgard...@vikingstorm.com wrote:
What you say especially resonates with me regarding the 'ease of use' wrt
hammering code in a highly iterative/productive way, and I have approached a
number of 'enterprise' size solutions in exactly that way with
I agree that namespaces should be designed to be consumed, but that can be
pretty taxing on the developer. In my libraries, I tend to split the
functions into whatever sub-namespaces I want to keep the organization easy
for me, and then import all the functions I want to expose into a
On 7 July 2011 09:39, Zach Tellman ztell...@gmail.com wrote:
I agree that namespaces should be designed to be consumed, but that can be
pretty taxing on the developer. In my libraries, I tend to split the
functions into whatever sub-namespaces I want to keep the organization easy
for me, and
On Jul 3, 2011, at 3:13 AM, Sean Corfield wrote:
Since I mostly work with 50-100kloc projects, I think 5-10kloc
projects are kinda small :)
My point was that I'm running into interesting questions even with a small
program. The answers are not obvious to me. There's evidence I'm not
2011/7/5 Stuart Halloway stuart.hallo...@gmail.com:
On large projects I do the following:
(2) Think of the consumer of the lib, not the author. As a user of Midje, I
would want all the utility fns in a single namespace (if they were separated
from the domain API at all).
In general, I have
On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
In general, I have found that namespaces should be larger than my OO
intuition would have them be.
One problem with scaling up namespaces, though, is that ongoing
invalid constant tag 32 issue with big enough input
On Tue, Jul 5, 2011 at 6:01 AM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
(1) Use require :as prefix everywhere. This felt ugly at first, but puts
pressure on naming in way that is beneficial as the codebase grows.
I've also started leaning toward that approach. At first I tended to
:use
On Tue, Jul 5, 2011 at 12:59 PM, Ken Wesson kwess...@gmail.com wrote:
On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
In general, I have found that namespaces should be larger than my OO
intuition would have them be.
One problem with scaling up namespaces,
On Sat, Jul 2, 2011 at 8:19 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
Were did you find the link between functional languages and close proximity of
errors ? That's a language design decision. You may want to use assertions
on your fns to validate inputs. That sould improve your
On Jul 4, 5:45 am, Christian Schuhegger
christian.schuheg...@gmail.com wrote:
Thanks for your feed-back. I already have RDF/OWL in my tool-kit. I am
only not sure if an ERP like system should be modeled along those
lines. But I did not put enough thought in that direction yet. Would
you base
On Jul 4, 1:26 pm, James Keats james.w.ke...@gmail.com wrote:
On Jul 4, 5:45 am, Christian Schuhegger
A good
book to get you started would SEMANTIC WEB for the WORKING ONTOLOGIST,
of which a second edition has recently come out. :-)
Sorry about the unintentional to get you started figure of
I think the issue with large programs is not the language but
software engineering.
A large program should be well designed and architected, and this is a
problem (I think) many
people in clojure and functional programming in general have. Clojure
is a very high level and concise language so I'll
No worries. I have the book on my shelf. The first version. But thanks
for making me aware of the second version.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new
Yes, exactly. I'm going to check that out.
Thanks Shantanu
Tim
On Sun, Jul 3, 2011 at 11:42 AM, Shantanu Kumar kumar.shant...@gmail.comwrote:
On Jul 3, 7:39 pm, Timothy Washington twash...@gmail.com wrote:
I'm using pre / post assertions quite a bit in a project I'm building.
And I
On Sat, Jul 2, 2011 at 7:25 PM, Brian Marick mar...@exampler.com wrote:
I have a codebase with 2.6kloc of production code and 4.8kloc of tests, and I
feel your pain (even despite having been a Lisp programmer in the early
80's). I'm not sure yet how to navigate the transition to 1.3 while
On Sat, Jul 2, 2011 at 8:56 PM, Nick Brown nwbr...@gmail.com wrote:
But not the lots of developers part. As much as I like
Clojure, it has nowhere near the level of developers languages like
Java or Python. And to be honest, that constraint is much more
convincing for most software managers
On Jul 3, 7:52 am, Glen Stampoultzis gst...@gmail.com wrote:
On 3 July 2011 11:26, Mark Engelberg mark.engelb...@gmail.com wrote:
But Clojure's
lack of a fail-fast philosophy has burned me several times, with
hard-to-track-down bugs that were far-removed from the actual cause.
The
On Jul 3, 2:26 am, Mark Engelberg mark.engelb...@gmail.com wrote:
Ideally, I was hoping to start a more in-depth discussion about the
pros and cons of programming in the large in Clojure than just
waxing poetic about Clojure/Lisp's capabilities in the abstract :)
I am yet to do a large
I'm using pre / post assertions quite a bit in a project I'm building. And I
too would love to see better or custom error messages for each assertion.
They do work great btw, as a way of failing fast.
Tim
On Sat, Jul 2, 2011 at 10:52 PM, Glen Stampoultzis gst...@gmail.com wrote:
On 3 July
On Jul 3, 7:39 pm, Timothy Washington twash...@gmail.com wrote:
I'm using pre / post assertions quite a bit in a project I'm building. And I
too would love to see better or custom error messages for each assertion.
That should be possible with a macro. For example, I use this:
I still have to do my personal large scale project in Clojure, but I
would like to share my thoughts so far. (10 years ago I implemented a
60k Common Lisp project; I never worked on more than 5k Clojure code
so far; the C++ and Java projects I was involved in reached 800k to 1M
lines of code).
I
On Jul 3, 5:21 pm, Christian Schuhegger
christian.schuheg...@gmail.com wrote:
Nevertheless for large connected data graphs I think something like a
data-schema is needed. Clojure would still follow its approach to only
deal with maps, but there is a descriptive meta-data level in addition
On Jul 3, 2011, at 3:13 AM, Sean Corfield wrote:
Since I mostly work with 50-100kloc projects, I think 5-10kloc
projects are kinda small :)
My point was that I'm running into interesting questions even with a small
program. The answers are not obvious to me. There's evidence I'm not alone,
On Sun, Jul 3, 2011 at 1:00 PM, Brian Marick mar...@exampler.com wrote:
My point was that I'm running into interesting questions even with a small
program. The answers are not obvious to me. There's evidence I'm not alone,
so those to whom the answers *are* obvious would help the community by
Brian Marick mar...@exampler.com writes:
This progression feels a lot more wasteful than it would have been in
Java (which has IDE support) or Ruby (which lets you mention a file
once and have it be available throughout the program). So I'd have
preferred to get it (more) right in the first
This is an unfinished thought: I think that the Single-Level-of-
Abstraction (SLA) principle promoted in OO needs to have a prominent
place in functional programming, too!
Each function should talk about the problem in its level of
abstraction, e.g. in its language. Functions related to the same
Thanks for your feed-back. I already have RDF/OWL in my tool-kit. I am
only not sure if an ERP like system should be modeled along those
lines. But I did not put enough thought in that direction yet. Would
you base an ERP like system on top of RDF/OWL?
--
You received this message because you
On Sat, Jul 2, 2011 at 12:21 PM, James Keats james.w.ke...@gmail.com wrote:
A very recent quote by Abelson is relevant:
One of the things I’m learning here (Google) is the experience of
working on these enormous programs. I just never experienced that
before. Previously a large program to me
On Jul 2, 8:33 pm, Mark Engelberg mark.engelb...@gmail.com wrote:
On Sat, Jul 2, 2011 at 12:21 PM, James Keats james.w.ke...@gmail.com wrote:
A very recent quote by Abelson is relevant:
One of the things I’m learning here (Google) is the experience of
working on these enormous programs. I
As for whether Clojure would work in a large corporate environment (or for
large software), I think that's more a function of the internal politics of
the organization. Many managers, understandably, go with a technology with
heavy library support and lots of developers. The common critique that
Ideally, I was hoping to start a more in-depth discussion about the
pros and cons of programming in the large in Clojure than just
waxing poetic about Clojure/Lisp's capabilities in the abstract :)
Yes, much of the initial excitement around Clojure comes from the
feeling of Wow, I can do so much
On Jul 2, 2011, at 8:26 PM, Mark Engelberg wrote:
My Clojure codebase is somewhere around 2-3kloc and I already feel
like I'm bumping up against some frustration when it comes time to
refactor, maintain, and extend the code, all while keeping up with
ongoing changes to libraries, contrib
On 3 July 2011 11:26, Mark Engelberg mark.engelb...@gmail.com wrote:
But Clojure's
lack of a fail-fast philosophy has burned me several times, with
hard-to-track-down bugs that were far-removed from the actual cause.
The larger my code grows, the more this annoys me, reminding me too
much
On Jul 3, 2:26 am, Mark Engelberg mark.engelb...@gmail.com wrote:
Ideally, I was hoping to start a more in-depth discussion about the
pros and cons of programming in the large in Clojure than just
waxing poetic about Clojure/Lisp's capabilities in the abstract :)
Yes, much of the initial
On Sat, 2 Jul 2011 18:26:21 -0700
Mark Engelberg mark.engelb...@gmail.com wrote:
Ideally, I was hoping to start a more in-depth discussion about the
pros and cons of programming in the large in Clojure than just
waxing poetic about Clojure/Lisp's capabilities in the abstract :)
Yes, much of
Many managers, understandably, go with a technology with
heavy library support and lots of developers. The common critique that
Lisp
isn't practical in industry, comes from that position. But Clojure,
sitting
atop the JVM, doesn't have that problem.
The library part, ok, sure (but if I'm writing
42 matches
Mail list logo
