how to write a programm in a short time with few bugs, and don't be very tired. is there some suggestions or skills?

TDD

it’s not that easy…

if it were, everyone would be doing TDD

my suggestion is write tons of code and read tons of code, ie practice

I've never tried full TDD, but I can say that using unit tests has one of the main advantages that I also see from functional programming: reducing the amount of contextual information I need to carry in order to understand something.

also tests help you push toward isolating side effects from functional logic, which is a good thing

Repl driven development gets my vote.

But really it's a combination of experience, testing in a repl, and writing simple code.

When the code is simple enough you can catch bugs by executing code in your head. And that's pretty much the way I code. Write code, mentally execute it as you go, test it in a repl when you aren't sure.

says the author of the go macro

🙂

@val_waeselynck did you take down your REPL video? I don’t seem to be able to access it

on the REPL, one game i've played and maybe gotten mileage out of is using the repl as little as possible, in an effort to have to think more about what's happening

i feel the repl has some addictive properties that can cause it to inhibit mind expansion, at least for me

I made a simple library to ease dumping contextual data from the repl and reinflating to be used in tests, also useful for dumping data in context inside an error handler to make regression tests https://github.com/noisesmith/poirot

of course, the more your code is driven by immutable data structures, the more useful the lib is (and really in clojure that's what we should be doing)

i'd say the most important thing is to think about your program before you write it. the more you understand about the actual underlying problems you're trying to solve, the faster you can write the code to solve it

Does that include not using the REPL to evaluate code as you write it in a source file?

Something that Stu said in one of his talks recently resonated with me and I've been trying to follow that approach -- not typing into the REPL, only typing into actual source files, and evaluating those forms (using the active REPL) in situ. I think that helps break the "context switch" that otherwise happens if you move back and forth between "source code" and "REPL" as two distinct things. I haven't fully internalized that workflow yet -- as you say, the REPL's interactivity is "addictive" -- but I think it better helps me think about my code since I can write a (comment ...) form and lay out all my thoughts about the solution, while embedding fragments of code that I can still evaluate without leaving the commentary context.

Using ProtoREPL means that I can get evaluation results displayed inline so I don't even need the REPL panel visible while I'm working on source code -- that helps a lot to avoid the temptation to just jump into the REPL to type a few fragments of code.

But going back to @doglooksgood's original question, like a few others have said, TDD can be a really good way to think about the problem space and to help arrive at the solution, as well as helping to drive your code. Using the eval-in-place approach means you can mix writing code fragments and actual tests together in one file while you're developing -- and then pull apart the tests into a separate namespace as things solidify.

Yeah, that is the approach I’ve used in Clojure. I can’t really work in the REPL, I write the code in a file, and evaluate. I find typing directly to the REPL to be a bit messy. But that might just be my brain not being able to remember stuff if I don’t write it out explicitly such that I can see it.

I only type directly on the repl when I’m trying to familiarize myself with a function I have never used, or forgot how it works

Even in that case, if you have an edit/repl setup that allows you to write a (comment ...) with calls to that function inside and evaluate those in place, you can not only avoid the typing-in-the-repl thing, you'll end up with some good notes for yourself.

yeah, sure

(but it takes discipline -- and I hadn't really thought about following that process "religiously" until I watched Stu's talk)

I normally use the comment when it is something that requires setup

Even tho' we have (comment ...) blocks in several of our source files that explain usage and setup and so on. Yeah, that, definitely!! ^

but for example, if I don’t remember how conj works, it is just easier to type it in the repl directly

@seancorfield which talk is that?

It was his talk to the Chicago Clojure group loosely about REPL-driven development as I recall...

https://vimeo.com/223309989

ah, thanks!