Lessons Learned from Adopting Clojure

[Jay Fields]

tl; dr: I'm presenting "Lessons Learned from Adopting Clojure" in
Chicago on Feb 11th:
http://www.eventbrite.com/e/goto-night-with-jay-fields-tickets-10366768283?aff=eorgf

Five years ago DRW Trading was primarily a Java shop, and I was
primarily developing in Ruby. Needless to say, it wasn't a match made
in heaven. Fast forward five years, Clojure is the second most used
language in the firm, and the primary language for several teams
(including mine). Clojure wasn't the first language that I've
introduced to an organization; however, it's unquestionably the most
successful adoption I've ever been a part of. The use of Clojure has
had many impacts on the firm: culturally, politically, and
technically. My talk will discuss general ideas around language
selection and maintenance trade-offs, and specific examples of what
aspects of Clojure made it the correct choice for us.

A few highlights

- Where to first introduce a new language and your role as the
language care-taker.
- REPL driven development, putting TDD's 'rapid feedback' to shame.
- Operations impact of adding a language - i.e. get ready for some DevOps.
- Functional programming, the Lisp Advantage, and their impact on
maintainability.

Of course, no good experience report is all roses. The adoption has
seen several hurdles along the way, and I'll happily to describe those
as well.

[Colin Yates]

Is there going to be online access during/after the event?  I would greatly value seeing this, but probably not enough to travel from the UK to Chicago :).

[Angel Java Lopez]

Interesting!

A question: did you abandon TDD? why?

IMO, TDD is a workflow that pushes for simplicity

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Rafael Peixoto de Azevedo]

+1 from Melbourne :)

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Cheers,
Rafael Peixoto de Azevedo
http://www.symprise.net
@RPAzevedo

[Mimmo Cosenza]

On Feb 4, 2014, at 1:06 PM, Jay Fields <j...@jayfields.com> wrote:

Hi Jay,

thanks for the report.  I only have few doubts about REPL making TDD to shame. 

I'm not a TDD practitioner, but I would not be so "tranchant" with it. 

The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a niche, because you can complement one with the other. 

I'm a fan of http://www.youtube.com/user/Misophistful?feature=watch stuff. he's able to be very clear and deep at the same time and if you take a look at his screencasts you would see that he uses both the REPL and the TDD at the same time. And he uses both unit test and simple-check tests as well. 

It is true that at  the moment the feedback-loop in clojurescript is not feasible, but the REPL experience with cljs has to be improved too to make it comparable with the clj REPL experience (at least with a nREPL compliant editor/ide).

Cheers

mimmo

- REPL driven development, putting TDD's 'rapid feedback' to shame.
- Operations impact of adding a language - i.e. get ready for some DevOps.
- Functional programming, the Lisp Advantage, and their impact on
maintainability.

Of course, no good experience report is all roses. The adoption has
seen several hurdles along the way, and I'll happily to describe those
as well.

[Jay Fields]

On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote:

thanks for the report.  I only have few doubts about REPL making TDD to shame. 

In this blog entry - http://blog.jayfields.com/2014/01/repl-driven-development.html - I demonstrate (very briefly, by design) my workflow. I also give my thoughts on TDD.

On Tuesday, February 4, 2014 7:24:21 AM UTC-5, Rafael Peixoto de Azevedo wrote:

+1 from Melbourne :)

I actually gave the talk in Melbourne, as part of YOW!. It was recorded and will be online at some point.

On Tuesday, February 4, 2014 7:22:06 AM UTC-5, Colin Yates wrote:

Is there going to be online access during/after the event?  I would greatly value seeing this, but probably not enough to travel from the UK to Chicago :).

This talk will not be recorded (afaik), but it's the same as the YOW! version, and that should be online soon. 

On Tuesday, February 4, 2014 8:02:28 AM UTC-5, ajlopez wrote:

A question: did you abandon TDD? why?

IMO, TDD is a workflow that pushes for simplicity

TDD, yes, for the most part. However, I still write a large number of tests. YMMV though, as you may find that TDD gives you better design direction. Assuming that's the case, I'd never try to convince you to do something else. This is an experience report, not a prescription for adopting Clojure. =) 

[Colin Yates]

Jay - in your demo I can't determine whether the (+ 2 2) expression is evaluated and the results pasted inline or whether you have manually pasted them?

I see you are using emacs, can you detail how you have configured emacs?

[Mimmo Cosenza]

On Feb 4, 2014, at 5:33 PM, Jay Fields <j...@jayfields.com> wrote:

On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote:

thanks for the report.  I only have few doubts about REPL making TDD to shame. 

In this blog entry - http://blog.jayfields.com/2014/01/repl-driven-development.html - I demonstrate (very briefly, by design) my workflow. I also give my thoughts on TDD.

Thanks Jay, in the post you were less "tranchant" about TDD. As I said I'm not a TDD practitioner, but recently I started to appreciated it by mixing my REPL based workflow, mostly when I'm writing portable CLJ/CLJS code (you can't image how many subtle differences I discovered between CLJ and CLJS in this way…..

Thanks again

mimmo

[Jay Fields]

Colin, I'm using emacs-live: http://overtone.github.io/emacs-live/

To evaluate (+ 2 2) and spit the results I'm using C-u C-x C-e

It's definitely an evaluation, not a copy paste of the results.

Cheers, Jay

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/huwg05Vl2RY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Sean Corfield]

Discussions around TDD / RDD (REPL-Driven-Development) probably need a separate thread but...

On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza <mimmo....@gmail.com> wrote:
> thanks for the report. I only have few doubts about REPL making TDD to shame.

I'm a strong advocate of TDD (well, BDD specifically) and I agree with Jay's comment insofar as you write a "test" expression in the REPL and it evaluates immediately. That's always faster than writing a test and running a test, by definition. That's all I took his comment to mean.

> The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a niche, because you can complement one with the other.

Indeed you can - and Jay does - and so do I. Especially now I'm using LightTable and can evaluate code in place in amongst my production code in one tabset and my expectations in another tabset. I have C-c , bound to evaluate a "run-tests" expression in my namespace so I can quickly evaluate and execute tests. Even so, live evaluation of "test code" is still a faster feedback loop.

Many of my test expressions become long-lived unit tests (expectations). Or they become production code. I still write expectations to clarify how to design APIs in the small (and APIs in the large as needed), but most of the red-green-refactor loop of TDD/BDD now comes from the REPL experiments for me.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Mimmo Cosenza]

On Feb 4, 2014, at 6:13 PM, Sean Corfield <se...@corfield.org> wrote:

>
>> The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a niche, because you can complement one with the other.
>
> Indeed you can - and Jay does - and so do I.

And me too. So we are all in the same boat :-).

mimmo

[Colin Yates]

Without starting a flame war - how are you finding LightTable for production?  Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it...  That is almost certainly because I don't have the time to invest in learning it and I expect it to do everything out of the box immediately and just the way I like it :)

[Göktuğ Kayaalp]

Colin Yates <colin...@gmail.com> writes:

AFAIK LightTable has paredit or sth. similar. Also, a great deal of
customisation is available via ClojureScript. I am personally favouring
Emacs as I am a polyglot programmer and do not only use Emacs as an
editor, but the programming and computing environment: This post is sent
via Emacs (Gnus), I write my blog posts with it, run shells, use git
(magit) and even view photos and PDFs.

If all you look is an editor/IDE-ish though, Emacs and LightTable are
quite the same thing indeed, except for the fact that Emacs has better
community and more packages.

> Without starting a flame war - how are you finding LightTable for
> production? Moving away from emacs and paredit would be quite hard and
> every time I look at LightTable I get really excited until I actually
> download and try it... That is almost certainly because I don't have the

> time to invest in learning it and I expect it to do everything out of ethe

> box immediately and just the way I like it :)
>
> On Tuesday, 4 February 2014 17:13:04 UTC, Sean Corfield wrote:
>>
>> Discussions around TDD / RDD (REPL-Driven-Development) probably need a
>> separate thread but...
>>

>> On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza <mimmo....@gmail.com<javascript:>>

>> wrote:
>> > thanks for the report. I only have few doubts about REPL making TDD to
>> shame.
>>
>> I'm a strong advocate of TDD (well, BDD specifically) and I agree with
>> Jay's comment insofar as you write a "test" expression in the REPL and it
>> evaluates immediately. That's always faster than writing a test and running
>> a test, by definition. That's all I took his comment to mean.
>>
>> > The REPL is great, that's for sure, but IMHO it does not relegate TDD
>> feedback/loop in a niche, because you can complement one with the other.
>>
>> Indeed you can - and Jay does - and so do I. Especially now I'm using
>> LightTable and can evaluate code in place in amongst my production code in
>> one tabset and my expectations in another tabset. I have C-c , bound to
>> evaluate a "run-tests" expression in my namespace so I can quickly evaluate
>> and execute tests. Even so, live evaluation of "test code" is still a
>> faster feedback loop.
>>
>> Many of my test expressions become long-lived unit tests (expectations).
>> Or they become production code. I still write expectations to clarify how
>> to design APIs in the small (and APIs in the large as needed), but most of
>> the red-green-refactor loop of TDD/BDD now comes from the REPL experiments
>> for me.
>>
>> Sean Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>>
>>
>>

--
— gk

[Sean Corfield]

On Feb 4, 2014, at 10:21 AM, Colin Yates <colin...@gmail.com> wrote:
> Without starting a flame war - how are you finding LightTable for production? Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it... That is almost certainly because I don't have the time to invest in learning it and I expect it to do everything out of the box immediately and just the way I like it :)

Like Emacs, it has its quirks(!) and it takes some adjustment after two years of using Emacs daily (and several years using Emacs twenty years back!).

I use the Emacs plugin, the Emacs mode (from the underlying CodeMirror editor), and the Paredit plugin. Plus some custom key mappings. It's not perfect but I'm getting used to the differences. Being able to customize it via Clojure (technically ClojureScript data structures) is a plus and a minus and whilst I've written one plugin, I based it heavily on someone else's so I haven't yet learned much about the LT internals... but the customization capabilities are VERY impressive.

At the moment, the biggest lack for me is something like magit but some folks are working on Git plugins so think that's just a short-term lack.

I really like LT's eval-in-place approach now I've gotten used to it - it's like having a REPL that's a 2D sketchpad rather than a linear sequence of evaluation "commands". I like that I can just try a bit of code out in the middle of my existing function definitions without having to switch to a REPL, so I'm finding I'm "growing" code directly inside my namespaces and then just wrapping each piece in defn and naming it once it does what I want, all on one "canvas".

I really like having a full-featured browser in my editor (that works cross-platform) and can act as a live evaluation target for .cljs and .js files (and .css and .html and so on).

I still keep Emacs open as my Git "client" and as my IRC client, but I don't edit anything with it.

[Norman Richards]

On Tue, Feb 4, 2014 at 5:20 PM, Sean Corfield <se...@corfield.org> wrote:

On Feb 4, 2014, at 10:21 AM, Colin Yates <colin...@gmail.com> wrote:
> Without starting a flame war - how are you finding LightTable for production?  Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it...  That is almost certainly because I don't have the time to invest in learning it and I expect it to do everything out of the box immediately and just the way I like it :)

Like Emacs, it has its quirks(!) and it takes some adjustment after two years of using Emacs daily (and several years using Emacs twenty years back!).

I'll provide a counterpoint to that.  Let me preface by saying I do not hate Light Table.  I supported the kickstarter, and I continue to follow the development as one of the best hopes for future Clojure development.  I am now using Light Table for Clojurescript development on our not-small-but-not-massive Clojure/Clojurescript UI at Threatgrid.  I find the live browser REPL interaction to be invaluable and finally makes me willing to invest more into the Clojurescript UI.  Up until now I've found the Clojurescript REPL support to be lacking.  Austin is promising, but I've still yet to find anyone who can demonstrate it functioning correctly in a non-demo environment.  Light Table works for this, and it works quite well.  

That being said, Light Table is barely usable as text editor and is a really terrible editor for Clojure in specific.  I hope (and believe) this will improve over time.  The token paredit barf/slurp shows some attention to details, and work is ongoing for an extended paredit mode.  But, I find that I spend a troubling large portion of my time in Light Table wrangling parenthesis and fighting the editor compared to the time I spend actually writing code.  The exact opposite is true in emacs. I spend almost no mental effort on the syntax/structure.  When I want to move an expression around or make a structural change, I can effect that change almost trivially with no distraction from the coding task at hand.  Obvious, there's a lot of practice and experience goes into that, but it's only because emacs has those capabilities in the first place.  

While every developer is different, I have a hard time imaging any emacs/paredit user would find editing in Light Table a pleasurable experience, so far as the act of writing the code is concerned.  There are many, many reasons to like Light Table and to use Light Table for now, but for day to day Clojure development, it's not even close to being ready for serious use. (only my opinion)  Still, everyone should give it a try, if you approach it from the perspective of being a tool that might be able to provide some unique value in certain situations, I don't think you'll be disappointed.

[Brian Marick]

On Feb 4, 2014, at 6:06 AM, Jay Fields <j...@jayfields.com> wrote:

> - REPL driven development, putting TDD's 'rapid feedback' to shame.

Pity I'll miss this, but I only come up to Chicago W-F.

What I've found is that having autotest in the REPL dissolves most conflict between TDD and REPL-driven development. Or to put it differently: having a REPL autotest makes writing a test less hassle than working in the repl - maybe 80% of the time. In the other 20%, the REPL is invaluable, though I always grate at the need to then "immortalize" the core of what I did in the REPL in repeatable tests.

(Actually, making clear distinctions like "80% doing this vs 20% doing that" feels like a poor reflection of my lived experience. I spend my time with four emacs windows open: a repl, the source, the tests of the source, and the miscellaneous window. I move very fluidly between them. Whatever source-of-immediate-gratification works best in the moment is always ready-to-hand.)

--------
Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

[Sean Corfield]

On Tue, Feb 4, 2014 at 6:07 PM, Brian Marick <mar...@exampler.com> wrote:
> I always grate at the need to then "immortalize" the core of what I did in the REPL in repeatable tests.

That's actually one of the things that bothered me in the Emacs REPL
world: working in the REPL was separate from working in my production
source and my test source. It's one of the things that has me really
hooked on LightTable. I have my source and test namespaces both open.
I have them both connected to a "REPL". I can evaluate any code, in
place, in either file. If I grow some code in the source file, I can
put (defn some-name [args]) in front of it and M-) slurps it into a
function - done! If I grow some code in the test file, I can put
(expect result-value) in front of it and M-) slurps it into a test -
done!

Since I moved to LightTable, I've found myself doing even more
REPL-Driven-Development than before because it's so much easier to
turn the experiments into code - or tests - in place.
--
Sean A Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

World Singles, LLC. -- http://worldsingles.com/

[Colin Yates]

Interesting - thanks all.  

My experience of Light Table is quite close to Norman's, although I discounted that *in my case* to not spending enough time with it.  Knowing a little about who Sean is (from following your blog/comments/clojure.jdbc, not stalking! :)) I put a lot of weight behind his opinion.  Brian's too, whose emacs's environment is similar to mine.  I happen to run midge :autotest in a separate console rather than in emacs with xmonad as my desktop manager (I mention xmonad because if you haven't checked it out you should - you will love it or hate it).

Guess I just need to carve out some time to play with it myself.

[John D. Hume]

On Wednesday, February 5, 2014, Sean Corfield wrote:

 It's one of the things that has me really
hooked on LightTable. I have my source and test namespaces both open.
I have them both connected to a "REPL". I can evaluate any code, in
place, in either file. If I grow some code in the source file, I can
put (defn some-name [args]) in front of it and M-) slurps it into a
function - done! If I grow some code in the test file, I can put
(expect result-value) in front of it and M-) slurps it into a test -
done!

Could you clarify the difference between LightTable's M-) and using C-M-x* in Emacs jacked into an nrepl session with Cider?

* `eval-defun` or whatever cider replaces that with for clojure. 

[Sean Corfield]

On Feb 5, 2014, at 5:39 AM, John D. Hume <duelin....@gmail.com> wrote:
> Could you clarify the difference between LightTable's M-) and using C-M-x* in Emacs jacked into an nrepl session with Cider?

M-) is paredit-forward-slurp-sexp in both LightTable and Emacs.

The key difference here is that LightTable can eval-in-place "live" inside a file without you needing to do anything but type code. You don't need to send expressions to a REPL and the results are displayed inline, right next to the expression, rather than in a separate REPL window or the minibuffer.

Essentially you get the benefit of the REPL and fast feedback without needing a separate REPL buffer.

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

[James Trunk]

As a TDD practitioner and Expectations user, I've been following this thread with great interest! 

@Jay: Will your change in thinking have any impact on Expectations?

My experience with TDD in Clojure has been an overwhelmingly positive one, and it seems like this thread might be a good place to discuss the subject with others.

RDD is an invaluable tool for evolving the shape of your functions, and it's a killer feature for REPL-based languages like Clojure. However, I mainly use RDD in the refactoring stage of TDD, and I still choose the overhead of writing tests before coding my solutions. Why do I do that? Well, I experience a number of benefits from TDD:

• A very clear separation of thinking between requirements and solution
  
• A constant focus on delivering the Minimum Viable Product
  
• Documentation, in English, of the expected behaviour of a function
  
• Documentation, in code, of example inputs and expected outputs of a function (especially useful in a dynamic language like Clojure)
  
• A continual reminder (and perfect opportunity) to refactor
  
• A refactoring confidence boost (i.e. if all my tests are still green, then I can be pretty confident in that refactor)
  
• The little bit of serotonin released in your brain when you make the next test turn green :-)
  
• Finishing a session with a red test gives you a great starting point for your next session and often helps you to get straight back into "the zone"
  
• A clear handover point if you're pair-programming

It's clear that developers who don't use TDD can (and do) develop extremely high quality solutions. However, for me personally, the list of benefits from doing TDD outweigh the cost of writing and maintaining the tests. I am a better programmer when I use TDD. I prefer jumping into other people's codebases when they have used TDD. I find it easier to get back into one of my own old projects when I've used TDD.

I also understand that most other programmers don't agree with me on this, which might mean that I'm wrong. :-)

Cheers,

James

[Angel Java Lopez]

+100

My English is "bad", but you expressed my position about TDD in general (I'm not a clojurian, yet, but I really appreciate TDD workflow in other technologies).

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[John D. Hume]

On Wed, Feb 5, 2014 at 1:27 PM, Sean Corfield <se...@corfield.org> wrote:

On Feb 5, 2014, at 5:39 AM, John D. Hume <duelin....@gmail.com> wrote:
> Could you clarify the difference between LightTable's M-) and using C-M-x* in Emacs jacked into an nrepl session with Cider?

M-) is paredit-forward-slurp-sexp in both LightTable and Emacs.

Sorry, I thought you were saying that kb shortcut is what "committed" the change to the running JVM. I now see your point that LightTable keeps trying to eval each top-level form and show you the result as you edit, whereas in Emacs you would have to issue a command to see the value of a top-level form. It seems like a small distinction, but I can see how it would make work more fluid.

The misconception I hope is disappearing is that REPL-driven development in Emacs necessarily involves lots of switching and copy-pasting back and forth between source file buffers and a REPL buffer. The video in Jay's blog post makes it pretty clear you never need to see the REPL prompt to use the REPL to change a running system.

[Jay Fields]

On Wed, Feb 5, 2014 at 4:35 PM, James Trunk <james...@gmail.com> wrote:
> As a TDD practitioner and Expectations user, I've been following this thread
> with great interest!
>
> @Jay: Will your change in thinking have any impact on Expectations?

I don't anticipate making any changes to expectations, but it's likely
that my preference for test-after did help shape some of expectations
syntax. Writing tests after is pretty boring work, which is likely at
least part of the reason that you're able to write such concise tests
using expectations.

[Sean Corfield]

FWIW, I find the language of Expectations to be much better suited to
describing the desired behaviors of a system I want to build than the
assertion-based language of clojure.test - so for me it's about
test-before, not test-after.

Sean

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Sean A Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

World Singles, LLC. -- http://worldsingles.com/

[Sean Corfield]

On Wed, Feb 5, 2014 at 1:56 PM, John D. Hume <duelin....@gmail.com> wrote:
> The misconception I hope is disappearing is that REPL-driven development in
> Emacs necessarily involves lots of switching and copy-pasting back and forth
> between source file buffers and a REPL buffer. The video in Jay's blog post
> makes it pretty clear you never need to see the REPL prompt to use the REPL
> to change a running system.

Agreed but my point was that in Emacs the results of your evaluations
are "elsewhere" and there is still a separate REPL buffer, even if you
actually work by editing a source file and sending expressions from
there to the REPL to operate on a "live" image.

I believe it was Mark Engelberg who talked about working *in* the REPL
and scrolling back through history and modifying and resubmitting
previous forms while he was developing his code. I think others have
also said they work that way. The objection was voiced (about
LightTable) that it's not a natural REPL-based workflow to have code
in a source file and "send" it to be evaluated.
--
Sean A Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

World Singles, LLC. -- http://worldsingles.com/

[Jay Fields]

On Wed, Feb 5, 2014 at 10:40 PM, Sean Corfield <se...@corfield.org> wrote:
> FWIW, I find the language of Expectations to be much better suited to
> describing the desired behaviors of a system I want to build than the
> assertion-based language of clojure.test - so for me it's about
> test-before, not test-after.

Thinking more on this, when I originally wrote expectations, I was
doing all TDD at the time (in IntelliJ). The main focus on
expectations syntax as always been around maintainability, and my tdd
or test-after opinions would always take a back seat to
maintainability.

I'm glad it works well for you Sean; hopefully your team is just as happy. =)

Cheers, Jay

[Korny Sietsma]

I've been doing something very similar, but using IntelliJ + Cursive Clojure - run Midje autotest inside the IDE for running tests, and also for manually evaluating snippets of code.

<plug> Cursive gives me a lot of what I had from Emacs - paredit editing, tight repl integration (alt-enter mapped to "eval sexp in repl" is used heavily), decent code formatting and indentation.  And also all the Gui stuff I always found clunky in Emacs: graphical directory tree, tool tips & autocomplete, graphical hints for things like git integration, code navigation including Java code.  I love emacs, but I'm increasingly frustrated by the limitations of it's mostly-text interface </plug>

(p.s. I saw Jay's talk at Yow, and it was excellent, though a bit depressing - we had pain getting Clojure working at our client, but far less than Jay did.  When the Yow videos come out you can compare his experiences with mine...)

- Korny

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Kornelis Sietsma  korny at my surname dot com http://korny.info

.fnord { display: none !important; }

[Sean Corfield]

On Feb 6, 2014, at 4:49 AM, Jay Fields <j...@jayfields.com> wrote:
> I'm glad it works well for you Sean; hopefully your team is just as happy. =)

Yup, they love Expectations.

Whenever we have to work on our WebDriver tests we always grumble because they are much more imperative and side-effecty so they are not really a match for Expectations - we use clojure.test instead because it's "do a bunch of side effecting stuff in the browser, assert that a bunch of conditions are true about the DOM, do a bunch more side effecting stuff, assert more DOM conditions, rinse and repeat"...

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

[edw...@kenworthy.info]

> (alt-enter mapped to "eval sexp in repl" is used heavily)

That's interesting but it doesn't seem to be a default and I can't find anything like 'eval sexp in repl' in the keymap nor anywhere else (using the IDEA search functionality under Preferences (OSX)).

[Colin Fleming]

Cursive doesn't come with default keybindings right now, due to the fact that IntelliJ's keybindings handling was a little unpredictable until recently. It's better since v13 so when I get some time I'll be sorting out a proper keymap.

In the meantime, the commands you want are "Run form before cursor in REPL" or "Run top form in REPL", which are under the Tools menu. They won't be present in the actual menu until you have a REPL started, but you can find them there in the Keymap settings in order to add keybindings for them.

For more options, visit https://groups.google.com/d/optout.