4 ms·

Did you use Prismatic's Schema [1] at the time? It seems like that was developed for your exact problem/use-case. By the way; I don't think Rich makes fun of T

by mtrimpe 13y ago

Did you use Prismatic's Schema [1] at the time? It seems like that was developed for your exact problem/use-case. By the way; I don't think Rich makes fun of TDD, but of how little of TDD is left when you're working with purely functional, side-effect free, code: passing functions data and verifying that you get back the right thing. In practice every Clojure coder will tell you debugging is still a pain but that it's not a problem as long as you check each small, pure, function for correctness ... which is pretty close to, if not the same as, TDD. [1] https://github.com/Prismatic/schema https://github.com/Prismatic/schema

sitkack 13y ago
Types don't prevent bugs (just classes of them) and small pure functions can still be composed into incorrect larger programs. ---- Edit to subdue harshness... I wrote a huge ETL tool in Python using all pure functions, list comprehensions, only named_tuple, no classes, no mutation, lots and lots of garbage, but it worked and worked well. I took a two pronged approach to testing 1. Proved each pure function in separate file, this was for me, this stuff never got run again. It was like a nursery for pure transformations 2. Wrote high level integration tests, 1 or 2 per module (about 20 total) 3. If I had a nasty bug, I would set a breakpoint in the debugger (pdb) and duplicate all of the state around me as best I could and put it into a functional test that WOULD get rerun as part of the automatic testing cycle. I would love a tool that could extract program state and put it into a test for me. 4. The majority of testing was to run the ETL tool on subsets of the input and validate the output, I had a handful of these of increasing complexity. The output validation was automatic. Testing a 4-10 line functions is waste once it is constructed. Higher level, whole module tests should cover an individual breakage of a smaller pure function. Tests are baggage (sometimes useful), just as static types are baggage (also sometimes useful). We need baggage, gotta wear clothes, read and eat.
- deleted 13y ago
  [deleted]
- tieTYT 13y ago
  > 3. If I had a nasty bug, I would set a breakpoint in the debugger (pdb) and duplicate all of the state around me as best I could and put it into a functional test that WOULD get rerun as part of the automatic testing cycle. I would love a tool that could extract program state and put it into a test for me. Amen. I've wanted this so many times in Java. A really hacky way to do this is to serialize your objects while debugging and deserialize them in your test. The problem is if the classes change your test won't work because you can't deserialize anymore. Encapsulation and data hiding really get in the way here.
  - sitkack 13y ago
    Bingo! I did serialize data structures and put them in my tests. In my case it was Python so everything was serialized into a readable textual format. Maybe use snappy compressed json? Being purely functional and having a fairly flat data structures really helped, I didn't have to serialize very far down. Another side effect of being flat is the garbage collector has less work to do. Reallocate early and often!
tieTYT 13y ago
No I haven't seen that, that looks pretty cool. It looks like a good middle ground between static types and core.typed. I don't like core.typed because what little research I've done shows that it actually becomes more verbose than java in some cases. That really seems like a step backwards.
pjmlp 13y ago
TDD is oversold. I enjoy picking at TDD guys by asking them to explain me how to TDD GUIs or algorithms like a B-Tree search in language X.
- coldtea 13y ago
  Amen. Where are the SCIENTIFIC studies that show TDD to be any better than going without TDD?

by mtrimpe 13y ago

sitkack 13y ago

Types don't prevent bugs (just classes of them) and small pure functions can still be composed into incorrect larger programs. ---- Edit to subdue harshness... I wrote a huge ETL tool in Python using all pure functions, list comprehensions, only named_tuple, no classes, no mutation, lots and lots of garbage, but it worked and worked well. I took a two pronged approach to testing 1. Proved each pure function in separate file, this was for me, this stuff never got run again. It was like a nursery for pure transformations 2. Wrote high level integration tests, 1 or 2 per module (about 20 total) 3. If I had a nasty bug, I would set a breakpoint in the debugger (pdb) and duplicate all of the state around me as best I could and put it into a functional test that WOULD get rerun as part of the automatic testing cycle. I would love a tool that could extract program state and put it into a test for me. 4. The majority of testing was to run the ETL tool on subsets of the input and validate the output, I had a handful of these of increasing complexity. The output validation was automatic. Testing a 4-10 line functions is waste once it is constructed. Higher level, whole module tests should cover an individual breakage of a smaller pure function. Tests are baggage (sometimes useful), just as static types are baggage (also sometimes useful). We need baggage, gotta wear clothes, read and eat.

deleted 13y ago
[deleted]
tieTYT 13y ago
> 3. If I had a nasty bug, I would set a breakpoint in the debugger (pdb) and duplicate all of the state around me as best I could and put it into a functional test that WOULD get rerun as part of the automatic testing cycle. I would love a tool that could extract program state and put it into a test for me. Amen. I've wanted this so many times in Java. A really hacky way to do this is to serialize your objects while debugging and deserialize them in your test. The problem is if the classes change your test won't work because you can't deserialize anymore. Encapsulation and data hiding really get in the way here.
- sitkack 13y ago
  Bingo! I did serialize data structures and put them in my tests. In my case it was Python so everything was serialized into a readable textual format. Maybe use snappy compressed json? Being purely functional and having a fairly flat data structures really helped, I didn't have to serialize very far down. Another side effect of being flat is the garbage collector has less work to do. Reallocate early and often!

tieTYT 13y ago

No I haven't seen that, that looks pretty cool. It looks like a good middle ground between static types and core.typed. I don't like core.typed because what little research I've done shows that it actually becomes more verbose than java in some cases. That really seems like a step backwards.

pjmlp 13y ago

TDD is oversold. I enjoy picking at TDD guys by asking them to explain me how to TDD GUIs or algorithms like a B-Tree search in language X.

coldtea 13y ago
Amen. Where are the SCIENTIFIC studies that show TDD to be any better than going without TDD?