8 ms·

Two interesting takeaways: > This is the beautiful thing about having a company that isn't on the stock market. Imagine you have a company that goes slower and

by dgb23 5y ago

Two interesting takeaways: > This is the beautiful thing about having a company that isn't on the stock market. Imagine you have a company that goes slower and slower every quarter, and then you confront the shareholders with the statement, that the way to solve it, is to do absolutely no new features for a quarter or two, refactor the code, learn new methodologies etc. I doubt that the shareholders would allow that. Luckily, we don't have any shareholders, and we understand the vital importance of this investment in the long run. Not only in the project, but also in our skill and knowledge, so we do better next time. This is reassuring the notion of what I think actually matters, what the real essence is of developing a product, may that be a piece of art and entertainment (like here) or a productivity tool etc. There are creators and there are consumers. We split them up by developers, designers, domain experts and so on, but what matters is that all the other participants, especially those who can exert power traditionally are not part of the essence and if not being careful and responsible, can easily add complexity and limitations that are entirely accidental and can even be harmful. This reminds me of the agile manifesto, modern UX approaches and other processes that are driven by creators, but are often and very unfortunately being bent over backwards to fit into hierarchical power structures. > TDD actually is the constant fast swithing between extending the tests and making them pass continously. So as you write tests, you write code to satisfy them basically at the same time. This allows you to instantly test what you write, and mainly use tests as specifiation of what the code should acctually do, which guides the thought process to make you think about where you are headed to, and to write code that is more structured and testable from the very beginning. The important notion here is that TDD is not about tests and correctness, but about development. It continuously checks assumptions and explores the surrounding code, state and data until a sufficient solution is found. If we squint a little we can see how closely related TDD with REPL Driven Development is. In essence it is the same thing and even has similar results, where the tests or REPL code can be left as an artifact for further, likely historical understanding. We know now that neither is sufficient for a high degree of correctness, but they are certainly useful for understanding and development.

rpastuszak 5y ago
> The important notion here is that TDD is not about tests and correctness, but about development. Yup, writing tests helps me sleep at night. TDD helps me manage my mental resources and iterate. (another reason is communication--we code for our colleagues first, then for the machine: https://sonnet.io/posts/code-sober-debug-drunk/ https://sonnet.io/posts/code-sober-debug-drunk/) IIRC smalltalk had a workflow where you'd debug and write your program at the same time. You'd just reach a path that has not been implemented yet, break, implement it and continue.
- dgb23 5y ago
  This „keeps working while it breaks“, does it have a name? It comes up in highly dynamic environments often like Smalltalk as you mentioned, but also Lisp, Erlang and others.
  - dkarp 5y ago
    I think this may be "REPL driven development" popular in the lisp community
    - dgb23 5y ago
      I meant more at the system/vm level. You're going to use a REPL (of some sort) for this, but the system needs to accommodate failure and just keep going, while giving you the opportunity to fix and change things. This has been implemented to varying degrees of reliability, granularity (in terms of preserving state) and utility. It's a common concept but I don't know the name for it! Examples: https://en.wikipedia.org/wiki/Continuation https://en.wikipedia.org/wiki/Continuation https://en.wikipedia.org/wiki/Fault_tolerance https://en.wikipedia.org/wiki/Fault_tolerance Maybe fault tolerance is the right word? But it doesn't imply that you actually modify and build the thing while it already runs.
      - astrange 5y ago
        It's not a great idea because failure could mean anything, and so you can't necessarily fix it. It's better to start over from the beginning. This is what reliable systems like Erlang do. https://en.wikipedia.org/wiki/Crash-only_software https://en.wikipedia.org/wiki/Crash-only_software
CraigJPerry 5y ago
For those curious about REPL driven development, this is a good example that i ran across recently: https://gist.github.com/daveray/1441520 https://gist.github.com/daveray/1441520 Even if you don’t follow along and try it, you can probably get the gist of how experimental / exploratory you can be.
- adamkl 5y ago
  For those who want to see some REPL driven development in action: https://vimeo.com/230220635 https://vimeo.com/230220635
bjornjajayaja 5y ago
I’d love to see a language where you write the tests and then the compiler creates the application code.
- oats 5y ago
  Is this not almost how logic programming (prolog, etc.) works? You tell the language some things which are true, and then it'll be able to infer answers to "questions" you ask: https://wiki.c2.com/?LogicProgramming https://wiki.c2.com/?LogicProgramming
  - JohnHaugeland 5y ago
    No. Not even a little bit.
    - oats 5y ago
      Could... could you enlighten me please?
  - iamwil 5y ago
    Yeah. I've often seen TDD where you act both as the logic programmer writing the tests and the imperative programmer writing the implementation.
  - victorNicollet 5y ago
    Let's say we work on the "reverse list" function. A few tests I could write are that the following clauses are true: rev([1], [1]) rev([1, 2, 3], [3, 2, 1]) And maybe also that the following clauses are false: rev([1, 2], [1, 2]) rev([], [1]) rev([1, 1], [1]) Is Prolog able to infer, from the above, that rev([4, 5], [5, 4]) ? Or to synthesize the general form rev([H|T],R) :- rev(T, RT), concat(RT,[H],R) ?
    - ffhhj 5y ago
      Sounds like NN training that could be achievable. The problem comes with unit testing, because the minimal testable unit could be more complex than a function.
lugged 5y ago
Its almost like Test Driven Development is the practice of using tests to drive development.
- dgb23 5y ago
  Much of TDD mantra is less about development but about (perceived) correctness, the article in question emphasizes the development part, where they describe their AHA moment.
  - berkes 5y ago
    > Much of TDD mantra is less about development but about (perceived) correctness, I have (seriously!) never heard it reference like this at all. Every introductory article, every book, every tutorial, every video about TDD (or BDD) that I consumed, emphasised that it is about "workflow", about "a way of development" and not about percieved correctness. Do note that the crucial different is that TDD > automated testing. In the sense that with TDD you write automated tests (that live in a test suite). But that "writing tests" or "developing a testsuite" is not nessecarily TDD.
    - dgb23 5y ago
      Yes in relation to automated testing it is obviously focusing on the development aspect, but as a whole method there is an at least implied and sometimes explicitly emphasized correctness benefit, that doesn't just come from automated tests but from the method of driving design through testing. In my personal opinion this claim goes too far. I think we can often explore aspects of design through code (including tests) but it can't be the main driver of design in any circumstance, nor does it by default or in general make our modules and programs more correct. The key benefit of doing this is that we have to think of code in terms of invariants and testability. But that is just one of many, sometimes conflicting factors and there are certainly more approaches to doing this than writing automated (unit-) tests.
    - hwayne 5y ago
      The original TDD book said it was both.
wpietri 5y ago
Yes, you're exactly right about REPL-driven development and TDD being the same spirit. I took to TDD pretty easily because I was already used to doing short run-it-and-see-if-it-works cycles. The main difference was that instead of checking via eyeball, I talk the computer to check it. This is slightly slower early on, but so much faster once a program is big enough that manually checking everything would take a while.
wpietri 5y ago
I appreciate this, but I still think it's a suboptimal approach: > that the way to solve it, is to do absolutely no new features for a quarter or two, refactor the code, learn new methodologies Even in a world without shareholders, we still are building things for users. 6 months without improvements has an effect on them, too. When possible, I think it's better to spread cleanup work out. Even if one spends 80% of the time on cleanup and 20% on features, that is much better for relationships than going dark for a quarter or two. And in my experience, continuing to do productive work during that period makes the behind-the-scenes improvements better.
- mikewarot 5y ago
  I've both watched all of Uncle Bob's videos (parts more than once), and been a long time Reddit/Factorio reader/game player. (The factory must grow!) They did exactly what you suggested! The relationship with the users never went dark. They kept up with bug fixes, and kept feeding new features at a more than acceptable pace. [Edit: Here's the pace of their status updates, as evidence at https://www.reddit.com/r/factorio/?f=flair_name%3A%22FFF%22 https://www.reddit.com/r/factorio/?f=flair_name%3A%22FFF%22 ] I didn't quite believe that Uncle Bob's lessons worked in the real world, but if the Wube team is sold on them, that's about as good as an endorsement as I'll ever get.
  - wpietri 5y ago
    Yay! Glad to hear it. I keep thinking I should try Factorio. But given amount of time friends have spent on it, I'm scared I'll never be heard from again. One of my friends has built a whole Grafana setup for it.
    - mikewarot 5y ago
      Factorio is easy to dump a ton of time into, if you are the type that likes solving puzzles and optimizing systems. You are wise in your caution.
      - elevatortrim 5y ago
truetraveller 5y ago
TDD is basically automated and "named" REPL-driven development. Which is very nice!
- infogulch 5y ago
  Oh that's an interesting take, and feels right to me. So the thing that holds back TDD is ergonomics (compile time/cached results) and maybe marketing.
indigochill 5y ago
Regarding the power structure observation, I've lately been weighing the merits of co-ops in the tech industry. Intuitively, it seems like a tech product owned by its users would lead to more product-centric decision-making. Leaving governance to shareholders who aren't necessarily directly involved in the product feels weird by comparison.
- dgb23 5y ago
  I think so too. A lot of that free energy is in the FOSS movement it seems, and there are plenty freelancers and single consultants in tech. This is a strong indicator that there is enough developers who primarily want to create, while having agency, responsibility and a direct communication channel. So why not start businesses that share these values and bring consumers and producers closer together?

by dgb23 5y ago

rpastuszak 5y ago

> The important notion here is that TDD is not about tests and correctness, but about development. Yup, writing tests helps me sleep at night. TDD helps me manage my mental resources and iterate. (another reason is communication--we code for our colleagues first, then for the machine: https://sonnet.io/posts/code-sober-debug-drunk/ https://sonnet.io/posts/code-sober-debug-drunk/) IIRC smalltalk had a workflow where you'd debug and write your program at the same time. You'd just reach a path that has not been implemented yet, break, implement it and continue.

dgb23 5y ago
This „keeps working while it breaks“, does it have a name? It comes up in highly dynamic environments often like Smalltalk as you mentioned, but also Lisp, Erlang and others.
- dkarp 5y ago
  I think this may be "REPL driven development" popular in the lisp community
  - dgb23 5y ago
    I meant more at the system/vm level. You're going to use a REPL (of some sort) for this, but the system needs to accommodate failure and just keep going, while giving you the opportunity to fix and change things. This has been implemented to varying degrees of reliability, granularity (in terms of preserving state) and utility. It's a common concept but I don't know the name for it! Examples: https://en.wikipedia.org/wiki/Continuation https://en.wikipedia.org/wiki/Continuation https://en.wikipedia.org/wiki/Fault_tolerance https://en.wikipedia.org/wiki/Fault_tolerance Maybe fault tolerance is the right word? But it doesn't imply that you actually modify and build the thing while it already runs.
    - astrange 5y ago
      It's not a great idea because failure could mean anything, and so you can't necessarily fix it. It's better to start over from the beginning. This is what reliable systems like Erlang do. https://en.wikipedia.org/wiki/Crash-only_software https://en.wikipedia.org/wiki/Crash-only_software

CraigJPerry 5y ago

For those curious about REPL driven development, this is a good example that i ran across recently: https://gist.github.com/daveray/1441520 https://gist.github.com/daveray/1441520 Even if you don’t follow along and try it, you can probably get the gist of how experimental / exploratory you can be.

adamkl 5y ago
For those who want to see some REPL driven development in action: https://vimeo.com/230220635 https://vimeo.com/230220635

bjornjajayaja 5y ago

I’d love to see a language where you write the tests and then the compiler creates the application code.

oats 5y ago
Is this not almost how logic programming (prolog, etc.) works? You tell the language some things which are true, and then it'll be able to infer answers to "questions" you ask: https://wiki.c2.com/?LogicProgramming https://wiki.c2.com/?LogicProgramming
- JohnHaugeland 5y ago
  No. Not even a little bit.
  - oats 5y ago
    Could... could you enlighten me please?
- iamwil 5y ago
  Yeah. I've often seen TDD where you act both as the logic programmer writing the tests and the imperative programmer writing the implementation.
- victorNicollet 5y ago
  Let's say we work on the "reverse list" function. A few tests I could write are that the following clauses are true: rev([1], [1]) rev([1, 2, 3], [3, 2, 1]) And maybe also that the following clauses are false: rev([1, 2], [1, 2]) rev([], [1]) rev([1, 1], [1]) Is Prolog able to infer, from the above, that rev([4, 5], [5, 4]) ? Or to synthesize the general form rev([H|T],R) :- rev(T, RT), concat(RT,[H],R) ?
  - ffhhj 5y ago
    Sounds like NN training that could be achievable. The problem comes with unit testing, because the minimal testable unit could be more complex than a function.

lugged 5y ago

Its almost like Test Driven Development is the practice of using tests to drive development.

dgb23 5y ago
Much of TDD mantra is less about development but about (perceived) correctness, the article in question emphasizes the development part, where they describe their AHA moment.
- berkes 5y ago
  > Much of TDD mantra is less about development but about (perceived) correctness, I have (seriously!) never heard it reference like this at all. Every introductory article, every book, every tutorial, every video about TDD (or BDD) that I consumed, emphasised that it is about "workflow", about "a way of development" and not about percieved correctness. Do note that the crucial different is that TDD > automated testing. In the sense that with TDD you write automated tests (that live in a test suite). But that "writing tests" or "developing a testsuite" is not nessecarily TDD.
  - dgb23 5y ago
    Yes in relation to automated testing it is obviously focusing on the development aspect, but as a whole method there is an at least implied and sometimes explicitly emphasized correctness benefit, that doesn't just come from automated tests but from the method of driving design through testing. In my personal opinion this claim goes too far. I think we can often explore aspects of design through code (including tests) but it can't be the main driver of design in any circumstance, nor does it by default or in general make our modules and programs more correct. The key benefit of doing this is that we have to think of code in terms of invariants and testability. But that is just one of many, sometimes conflicting factors and there are certainly more approaches to doing this than writing automated (unit-) tests.
  - hwayne 5y ago
    The original TDD book said it was both.

wpietri 5y ago

Yes, you're exactly right about REPL-driven development and TDD being the same spirit. I took to TDD pretty easily because I was already used to doing short run-it-and-see-if-it-works cycles. The main difference was that instead of checking via eyeball, I talk the computer to check it. This is slightly slower early on, but so much faster once a program is big enough that manually checking everything would take a while.

wpietri 5y ago

I appreciate this, but I still think it's a suboptimal approach: > that the way to solve it, is to do absolutely no new features for a quarter or two, refactor the code, learn new methodologies Even in a world without shareholders, we still are building things for users. 6 months without improvements has an effect on them, too. When possible, I think it's better to spread cleanup work out. Even if one spends 80% of the time on cleanup and 20% on features, that is much better for relationships than going dark for a quarter or two. And in my experience, continuing to do productive work during that period makes the behind-the-scenes improvements better.

mikewarot 5y ago
I've both watched all of Uncle Bob's videos (parts more than once), and been a long time Reddit/Factorio reader/game player. (The factory must grow!) They did exactly what you suggested! The relationship with the users never went dark. They kept up with bug fixes, and kept feeding new features at a more than acceptable pace. [Edit: Here's the pace of their status updates, as evidence at https://www.reddit.com/r/factorio/?f=flair_name%3A%22FFF%22 https://www.reddit.com/r/factorio/?f=flair_name%3A%22FFF%22 ] I didn't quite believe that Uncle Bob's lessons worked in the real world, but if the Wube team is sold on them, that's about as good as an endorsement as I'll ever get.
- wpietri 5y ago
  Yay! Glad to hear it. I keep thinking I should try Factorio. But given amount of time friends have spent on it, I'm scared I'll never be heard from again. One of my friends has built a whole Grafana setup for it.
  - mikewarot 5y ago
    Factorio is easy to dump a ton of time into, if you are the type that likes solving puzzles and optimizing systems. You are wise in your caution.
    - elevatortrim 5y ago

truetraveller 5y ago

TDD is basically automated and "named" REPL-driven development. Which is very nice!

infogulch 5y ago
Oh that's an interesting take, and feels right to me. So the thing that holds back TDD is ergonomics (compile time/cached results) and maybe marketing.

indigochill 5y ago

Regarding the power structure observation, I've lately been weighing the merits of co-ops in the tech industry. Intuitively, it seems like a tech product owned by its users would lead to more product-centric decision-making. Leaving governance to shareholders who aren't necessarily directly involved in the product feels weird by comparison.

dgb23 5y ago
I think so too. A lot of that free energy is in the FOSS movement it seems, and there are plenty freelancers and single consultants in tech. This is a strong indicator that there is enough developers who primarily want to create, while having agency, responsibility and a direct communication channel. So why not start businesses that share these values and bring consumers and producers closer together?