What do you all think of Clojure's "REPL-driven development" method?

[shymega]

Hi there.

I’m from primarily Clojure, and I always liked the REPL-driven deployment method that Clojurists use, with the REPL and dynamically building applications that way.

So, further to that end, I was wondering how easy that would be with Elixir/Erlang?

Any thoughts? I love Elixir and Erlang, but I do definitely miss the Clojure way of developing applications.

[NobbZ]

Can you elaborate what that means for you? I have a REPL active virtually all the time, hot reloading my code to play with my API. Is this what you are referring to?

[OvermindDL1]

@NobbZ

Can you elaborate what that means for you? I have a REPL active virtually all the time, hot reloading my code to play with my API. Is this what you are referring to?

I’ve not used clojure, but if it is anything like lisp (since it was built like lisp) then a lisp program is not so much source code as it is a running state, and that state can change and mutate over time, and you can save out that state and reload it back in. Maybe clojure does the same? If that is what is meant then the BEAM has nothing like that. If that is not what was meant than more clarification needed. ^.^;

[shymega]

@OvermindDL1

I’ve not used clojure, but if it is anything like lisp (since it was built like lisp) then a lisp program is not so much source code as it is a running state, and that state can change and mutate over time, and you can save out that state and reload it back in. Maybe clojure does the same? If that is what is meant then the BEAM has nothing like that. If that is not what was meant than more clarification needed. ^.^;

You’ve hit the nail on the head there. I wasn’t really quite sure how to describe what I meant, thanks!

It’s the one thing I miss from Clojure, but I suppose keeping a REPL open and reloading works well, too.

Thanks for your help, all.

[peerreynders]

@OvermindDL1

that state can change and mutate over time

Unlike Lisp, Clojure embraces immutability - save where mutability is necessary, like for Java interop (unless I completely misunderstood your meaning).

Now, if I’ve got my head on straight the primary impediment to “iex-driven development” is that you can’t define modules. Now keep in mind that I’m not the best person to talk about “REPL-driven development” as I’ve always found it a bit overhyped (possibly because I consider myself a lazy/slow typist). I’ve always been happy enough to kludge around with:

• First terminal window running a text editor
• Second terminal for running some kind of build script
• Third terminal for running some kind of test script

So with “iex-driven development” you still need two terminals open - one to edit your modules another running iex where you have to manually re-compile and re-load the modified modules before you can run the updated code.

Edit: I stand corrected.

[michalmuskala]

You can totally define modules in iex (unlike in Erlang’s shell).

[NobbZ]

Can you save them back? Ebin and source? Alter them easily? Meaning add a function and keep all that were already there beforehand? Delete a function?

[peerreynders]

@NobbZ

Can you save them back? Ebin and source?

I don’t recall being able to do that even in Clojure - but then again maybe I didn’t press it far enough. Basically I was just experimenting with alternate solution approaches.

Alter them easily? Meaning add a function and keep all that were already there beforehand? Delete a function?

This I remember doing in Clojure - essentially it felt like manipulating an in-memory representation of the code that would be run through the reader next time I executed something. In iex I’m not sure I would know where to start … in iex I basically stick to c/2, r/1.

[michalmuskala]

This should be definitely doable on OTP 20 with the new debug info - I mean both adding or modifying a single function.

[OvermindDL1]

@peerreynders

Unlike Lisp, Clojure embraces immutability - save where mutability is necessary, like for Java interop (unless I completely misunderstood your meaning).

Wrong meaning.

I mean that you can, for example, redefine a function and the new version is used from then on (old references still reference the old function, it is ‘safe’ in that way).

REPL driven development is basically you write code in the REPL, it is put in the system in real-time, any time you save you are saving a ‘dump’ of the system (no source code), and you can pick it up where it left off at any time. This was very popular in business distributing LISP since anyone could just spool up the server from the state and they could introspect the system, but no code distributed.

@michalmuskala

You can totally define modules in iex (unlike in Erlang’s shell).

Easily yep, it just lacks the ability to write out the running ‘state’ of the system.

@peerreynders

This I remember doing in Clojure - essentially it felt like manipulating an in-memory representation of the code that would be run through the reader next time I executed something. In iex I’m not sure I would know where to start … in iex I basically stick to c/2, r/1.

Yeah the LISP state was utter magic compared to anything else out at the time, even compared to today it is magic. ^.^

[mischov]

I think Elixir has quite a bit going for it REPL-wise (and I came to it from Clojure).

IEx is perfectly useful for exploration (one of the main things I used it for in Clojure), and can come close to the reloaded workflow if you’re using applications or ets to hold state. It has pretty good code reloading, though there are gotchas (like changing config)… but then there are gotchas in Clojure too.

My workflow with the REPL isn’t quite as smooth with emacs as it was in Clojure, but that’s more the result of not having spent the time to improve it than the tools being missing. I generally just iex -S mix in a terminal and flip over to it when I want to check something. Something like Cortex would probably improve things even more.

[OvermindDL1]

@mischov

Something like Cortex would probably improve things even more.

Huh, that’s really cool… Not hard to do either, that is a great idea!

[tmbb]

Since nobody has said it yet, I will: REPL-driven development in clojure is a crutch. It’s needed because compiling a full clojure project is extremely slow. As a result, due to what I can only assume is Stockholm syndrome, clojure developpers start praising REPL drive development just to avoid having to compile the project in full.

[mischov]

@tmbb

Since nobody has said it yet, I will: REPL-driven development in clojure is a crutch. It’s needed because compiling a full clojure project is extremely slow. As a result, due to what I can only assume is Stockholm syndrome, clojure developpers start praising REPL drive development just to avoid having to compile the project in full.

There may be some truth to that statement, but that kind of hyperbole is no better than:

TDD in dynamic languages is a crutch. It’s needed because writing code in dynamic languages is extremely error prone. As a result, due to what I can only assume is Stockholm syndrome, dynamic language developers start praising TDD just to avoid losing their minds.

I personally find an exploratory style of programming that makes heavy use of the REPL beneficial and satisfying, but it’s always just one tool in the belt. Use it when it makes sense and reach for something else when it doesn’t.

[tmbb]

@mischov

Use it when it makes sense and reach for something else when it doesn’t.

My point is that clojure makes it very hard to reach for something else (because It’s very slow).

I also think that many tests (not all, of course!) are actually a crutch for the lack of static types I won’t cokment on TDD because I’ve never used such thing.

[OvermindDL1]

@mischov

There may be some truth to that statement, but that kind of hyperbole is no better than:

I kind of think both of those statements are true. ^.^
Does not mean that REPL driven development in LISP is not fun, I’ve certainly done my share of it! ^.^

@tmbb

I also think that many tests (not all, of course!) are actually a crutch for the lack of static types I won’t cokment on TDD because I’ve never used such thing.

/me coughs

[notriddle]

@tmbb

Since nobody has said it yet, I will: REPL-driven development in clojure is a crutch. It’s needed because compiling a full clojure project is extremely slow. As a result, due to what I can only assume is Stockholm syndrome, clojure developpers start praising REPL drive development just to avoid having to compile the project in full.

Then why do so many other LISPs, which don’t compile as slowly as Clojure, also make heavy use of the REPL during development?

[shymega]

Well, this got quite a big response. I’m grateful for the variety of views, and it’s been interesting to read through them all!

Thanks for your input, folks. Although I should add that I’m not closing this topic, so feel free to carry on discussing!

[DianaOlympos]

I also think that many tests (not all, of course!) are actually a crutch as are static types used in term of checking reliability I won’t cokment on TDD because it is the same problem as static types.

My take on it

[OvermindDL1]

@shymega

Well, this got quite a big response. I’m grateful for the variety of views, and it’s been interesting to read through them all!

Heh, sometimes I even debate by ‘being’ the opposite stance of what I truly think, just to see what new views come out (I’ve surprised myself when I take up my opposite view, sometimes I learn some really cool things!). ^.^