On Thu, Jul 7, 2011 at 2:45 AM, Feng Shen 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
https://github.com/tcrayford/clojure-
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 wrote:
> Ideally, I was hoping to start a more in-depth discussion ab
On 7 July 2011 09:39, Zach Tellman 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 then import al
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
higher-l
On Wed, Jul 6, 2011 at 3:18 AM, Johan Gardner 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 extremely
> robust result
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 Taoussanis
On Wed, Jul 6, 2011 at 3:49 AM, Peter Taoussanis 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 time constraints, e
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 Tue, Jul 5, 2011 at 2:58 PM, David Nolen wrote:
> On Tue, Jul 5, 2011 at 12:59 PM, Ken Wesson wrote:
>>
>> On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
>> wrote:
>> > In general, I have found that namespaces should be larger than my OO
>> > intuition would have them be.
>>
>> One problem w
On Tue, Jul 5, 2011 at 12:59 PM, Ken Wesson wrote:
> On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
> 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
On Tue, Jul 5, 2011 at 6:01 AM, Stuart Halloway
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 clojure.* namespaces
On Tue, Jul 5, 2011 at 9:01 AM, Stuart Halloway
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 files (see other
thre
2011/7/5 Stuart Halloway :
> 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 found that namespaces s
> 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
Yes, exactly. I'm going to check that out.
Thanks Shantanu
Tim
On Sun, Jul 3, 2011 at 11:42 AM, Shantanu Kumar wrote:
>
>
> On Jul 3, 7:39 pm, Timothy Washington 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 custo
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 me
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
On Jul 4, 1:26 pm, James Keats 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 speech; I
note yo
On Jul 4, 5:45 am, Christian Schuhegger
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 an ERP like system on top
On Sat, Jul 2, 2011 at 8:19 PM, Luc Prefontaine
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 ability to track
> errors
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 are
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 l
Brian Marick 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 place.
Have you
On Sun, Jul 3, 2011 at 1:00 PM, Brian Marick 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
> describing th
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 Jul 3, 5:21 pm, Christian Schuhegger
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
> that explains the connection
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 t
On Jul 3, 7:39 pm, Timothy Washington 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:
https://bitbucket.org/kumarshant
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 wrote:
> On 3 July 2011 11:26, Mark E
On Jul 3, 2:26 am, Mark Engelberg 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 program in clojure, I st
On Jul 3, 7:52 am, Glen Stampoultzis wrote:
> On 3 July 2011 11:26, Mark Engelberg 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 t
On Sat, Jul 2, 2011 at 8:56 PM, Nick Brown 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 than the lib
On Sun, Jul 3, 2011 at 1:13 AM, Sean Corfield wrote:
> On Sat, Jul 2, 2011 at 7:25 PM, Brian Marick wrote:
>> I'm not sure yet how to navigate the transition to 1.3 while retaining
>> backwards compatibility.
At World Singles we moved to 1.3 pretty much as a matter of course,
mostly because I'm
On Sat, Jul 2, 2011 at 7:25 PM, Brian Marick 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 retaining
> backwar
"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 writin
On Sat, 2 Jul 2011 18:26:21 -0700
Mark Engelberg 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 excit
On Jul 3, 2:26 am, Mark Engelberg 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 excitement around Cl
On 3 July 2011 11:26, Mark Engelberg 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 of my days tracking
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 s
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 muc
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 Li
On Jul 2, 8:33 pm, Mark Engelberg wrote:
> On Sat, Jul 2, 2011 at 12:21 PM, James Keats 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.
42 matches
Mail list logo
