5 ms·

> If it now works correctly, then congratulations; you found the problem! This notion if “correct” is “finished the current example as intended”. Running a sui

by qznc 6y ago

> If it now works correctly, then congratulations; you found the problem! This notion if “correct” is “finished the current example as intended”. Running a suite of unit tests would give me more confidence. Even that is only for programming in the small and that is comparatively easy to programming in the large. I don’t see how a REPL would help there. That means a REPL makes easy things easier and hard things are unaffected. Does not sound like a competitive advantage to me.

nsm 6y ago
Writing unit tests _is_ part of the interactive development style in Smalltalk. In fact TDD arose out of a lot of (ex)-Smalltalk developers. When you have an environment as mikelevins describes, where the debugger allows you to author-as-you-go, you can start by writing a test and fill in the implementation and have your test go green, all in one very tight loop. You actually can run a bunch of unit tests in Smalltalk with a single-click, get results, and be dropped into a full authoring environment when tests fail, with the bonus that you can just fix the code and resume execution to have the test go green. Modern Java IDEs can probably do this (I've no experience with Java), but you've to understand that this was possible in Smalltalk several decades ago.
coldtea 6y ago
>Even that is only for programming in the small and that is comparatively easy to programming in the large. I don’t see how a REPL would help there. Because the right way of programming in the large is programming in the small and combining things (e.g. functions, components, classes, whatever, etc.), not building some huge monolithic monstrocity (this is orthogonal to monoliths vs microservices btw). Plus, this "programming in the large", when it gets to, say, 10.000.000 lines of code will still have bugs and behavior you need to check/search for/and fix in individual parts, and this "restarting/dynamic change" REPL will still be a great tool here.

by qznc 6y ago

nsm 6y ago

Writing unit tests _is_ part of the interactive development style in Smalltalk. In fact TDD arose out of a lot of (ex)-Smalltalk developers. When you have an environment as mikelevins describes, where the debugger allows you to author-as-you-go, you can start by writing a test and fill in the implementation and have your test go green, all in one very tight loop. You actually can run a bunch of unit tests in Smalltalk with a single-click, get results, and be dropped into a full authoring environment when tests fail, with the bonus that you can just fix the code and resume execution to have the test go green. Modern Java IDEs can probably do this (I've no experience with Java), but you've to understand that this was possible in Smalltalk several decades ago.

coldtea 6y ago

>Even that is only for programming in the small and that is comparatively easy to programming in the large. I don’t see how a REPL would help there. Because the right way of programming in the large is programming in the small and combining things (e.g. functions, components, classes, whatever, etc.), not building some huge monolithic monstrocity (this is orthogonal to monoliths vs microservices btw). Plus, this "programming in the large", when it gets to, say, 10.000.000 lines of code will still have bugs and behavior you need to check/search for/and fix in individual parts, and this "restarting/dynamic change" REPL will still be a great tool here.