4 ms·

TDD can help with this. I more often than not, will write a unit test or functional test first, then work on the code for that test where I'm just running that

by ece 9y ago

TDD can help with this. I more often than not, will write a unit test or functional test first, then work on the code for that test where I'm just running that one test until it succeeds. After I have individual parts working, I will integrate everything, which again will just be another integration test run from the IDE. I realize this isn't always possible, and is probably easier to do in a managed language, but you can cut down on iteration times by mostly forcing the IDE to do incremental compiles. You can work in real-time on code that might take tens of minutes for a full build. TDD is fun.

jnbiche 9y ago
Despite being downvoted, this assertion about TDD is true. It can provide a very interactive experience when programming, even with languages with little natural interactivity. But you have to know how to set up the tests.
- breatheoften 9y ago
  I'm enjoying wallabyjs with jest and vscode. It's quite fun having feedback from test execution always available in the IDE. I don't have a long build step for my codebase (compiling typescript just takes a few seconds and incremental is instant) -- but I do avoid lengthy deployment cycles -- deploying code to aws lambda takes quite awhile.
- ece 9y ago
  A good IDE will go a long way here. Any of the IntelliJ IDEs are interactive in almost any aspect of technical coding. Setting up and running a test is a left click, if you've written the function and annotated it in Scala. I've been trying to use Atom for some embedded coding, and some of the plugins for it are pretty good, but not completely free. MS VS is up there too, but I haven't used it in a long time. Off course, writing testable code using OO almost requires dependency injection IMO. With FP, it's almost trivial.
tcbawo 9y ago
have you ever tried BDD (behavior driven development)? one of the interesting aspects of this is being able to develop the test implementation in a different (possible more expressive) language
- ece 9y ago
  For web development, yes. Once you know pretty much what you want, and have a good idea of how you're going to go about implementing it, it can be fast. If you're new, don't know what you want, and are starting out on a framework, it can be an impassable chasm. If you're just experimenting, it's also a bit too much. Starting with a simple unit test or spec (what I meant by functional testing, though this can be BDD too) can be easier to start with and change as you figure out what you want. Even with specs, or a BDD framework like you said, no need to bring in a whole new DSL unless you need it IMHO, others may disagree.
  - tcbawo 9y ago
    I've never done professional Web Development. But, I found BDD useful for describing correct behavior to the end user in a readable, yet functional and extensible way. When it works well, it eliminates the telephone game of capturing requirements and translating into brittle test cases which are readable only by the developers.
didibus 9y ago
It's true, but it's more a treatment then addressing the root cause. Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you wanted TDD, but really you wanted an interactive REPL." My gripe with TDD, is that it gets tedious in its own way. Always needing to eventually mock some aspects of the code, and always working in the small, you start feeling distant from the medium and large picture of the code.
- ece 9y ago
  It's a pretty good treatment. I think the solving the root cause would be something like a constant time compiler, which I don't think is going to happen. You don't need to mock at all if you do DI and modularity well in Guice or Spring or something else (it can be the rare exception for a few libraries that use say private constructors). You can also write 3-5 line tests that will absolutely test everything in your program, and be able to debug it line by line in a debugger. So, I'm not sure I would agree with Rich Hickey on this. REPLs are no substitute for a good IDE and debugger running a series of declarative tests.
  - didibus 9y ago
    Not all REPLs, just like you had to preface debugger with good, you need to preface REPL with good. You really need to give a good REPL a fair try to know what I mean. Most people also thought tests wouldn't add much worth, and took a long time to bother giving tests a fair chance. Good interactive REPLs are the same. Try it out, not one day of it, spend a week, then decide. It helps if you know someone that can show you. At my work, a lot of devs try Clojure and don't like it. Then I sit down with them and show them how you're supposed to use the REPL. They always turn around after that, and acknowledge how awesome the REPL is. That's why I emphasize on fair chance. Its easy to try it and miss the point, not use it how it is meant to be used. Also, the language must embrace it, if its tacked on, it rarely works. It has to be first class. Ya, I agree, tests are a good treatment, the best for most languages. A good interactive REPL is often better though. Clojure has tests, good IDEs and debuggers. Yet people don't care about them as much, because the REPL solves most problems. In return, it means the IDEs and debuggers aren't as good as Java, because people care less and so also invest less in them, and sometimes I'd want a better IDE or debugger to complement the great REPL experience, but I wouldn't trade the great interactive REPL for them.

by ece 9y ago

jnbiche 9y ago

Despite being downvoted, this assertion about TDD is true. It can provide a very interactive experience when programming, even with languages with little natural interactivity. But you have to know how to set up the tests.

breatheoften 9y ago
I'm enjoying wallabyjs with jest and vscode. It's quite fun having feedback from test execution always available in the IDE. I don't have a long build step for my codebase (compiling typescript just takes a few seconds and incremental is instant) -- but I do avoid lengthy deployment cycles -- deploying code to aws lambda takes quite awhile.
ece 9y ago
A good IDE will go a long way here. Any of the IntelliJ IDEs are interactive in almost any aspect of technical coding. Setting up and running a test is a left click, if you've written the function and annotated it in Scala. I've been trying to use Atom for some embedded coding, and some of the plugins for it are pretty good, but not completely free. MS VS is up there too, but I haven't used it in a long time. Off course, writing testable code using OO almost requires dependency injection IMO. With FP, it's almost trivial.

tcbawo 9y ago

have you ever tried BDD (behavior driven development)? one of the interesting aspects of this is being able to develop the test implementation in a different (possible more expressive) language

ece 9y ago
For web development, yes. Once you know pretty much what you want, and have a good idea of how you're going to go about implementing it, it can be fast. If you're new, don't know what you want, and are starting out on a framework, it can be an impassable chasm. If you're just experimenting, it's also a bit too much. Starting with a simple unit test or spec (what I meant by functional testing, though this can be BDD too) can be easier to start with and change as you figure out what you want. Even with specs, or a BDD framework like you said, no need to bring in a whole new DSL unless you need it IMHO, others may disagree.
- tcbawo 9y ago
  I've never done professional Web Development. But, I found BDD useful for describing correct behavior to the end user in a readable, yet functional and extensible way. When it works well, it eliminates the telephone game of capturing requirements and translating into brittle test cases which are readable only by the developers.

didibus 9y ago

It's true, but it's more a treatment then addressing the root cause. Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you wanted TDD, but really you wanted an interactive REPL." My gripe with TDD, is that it gets tedious in its own way. Always needing to eventually mock some aspects of the code, and always working in the small, you start feeling distant from the medium and large picture of the code.

ece 9y ago
It's a pretty good treatment. I think the solving the root cause would be something like a constant time compiler, which I don't think is going to happen. You don't need to mock at all if you do DI and modularity well in Guice or Spring or something else (it can be the rare exception for a few libraries that use say private constructors). You can also write 3-5 line tests that will absolutely test everything in your program, and be able to debug it line by line in a debugger. So, I'm not sure I would agree with Rich Hickey on this. REPLs are no substitute for a good IDE and debugger running a series of declarative tests.
- didibus 9y ago
  Not all REPLs, just like you had to preface debugger with good, you need to preface REPL with good. You really need to give a good REPL a fair try to know what I mean. Most people also thought tests wouldn't add much worth, and took a long time to bother giving tests a fair chance. Good interactive REPLs are the same. Try it out, not one day of it, spend a week, then decide. It helps if you know someone that can show you. At my work, a lot of devs try Clojure and don't like it. Then I sit down with them and show them how you're supposed to use the REPL. They always turn around after that, and acknowledge how awesome the REPL is. That's why I emphasize on fair chance. Its easy to try it and miss the point, not use it how it is meant to be used. Also, the language must embrace it, if its tacked on, it rarely works. It has to be first class. Ya, I agree, tests are a good treatment, the best for most languages. A good interactive REPL is often better though. Clojure has tests, good IDEs and debuggers. Yet people don't care about them as much, because the REPL solves most problems. In return, it means the IDEs and debuggers aren't as good as Java, because people care less and so also invest less in them, and sometimes I'd want a better IDE or debugger to complement the great REPL experience, but I wouldn't trade the great interactive REPL for them.