Won't you also be more likely to write code based on data that you happen to have in the current situation, but not for data that covers every situation?
E.g. code that accesses an optional property as if it was always present, because it happens to be present when you're writng the code, etc.
That seems like a possible pitfall when relying on a REPL heavily, but I haven't used such a language myself, so can't speak from experience.
And with TDD, aren't you ore likely to write code based on the current tests you have, but not code that covers every situation?
Any time writing code, you (should) aim for the general situation and then test it with whatever edge-cases you think of at the time. The REPL lets you live-test. I know many people who dump their REPL history to a file and turn them into tests.
My attitude with tests is not to write individual tests when I can write property-based tests. The payoff from the latter is considerable. Let the computer do the work of generating and running tests; its time is worth a whole lot less than mine.
For individual tests, say for coverage, these should also be generated automatically if possible, say by looking for inputs that kill mutants. I've backburned a Common Lisp system for doing this, generating mutants from Common Lisp source forms and automatically searching for and minimizing inputs that kill new mutants. Maybe one day I'll finish this and put it out there for general use.
My point was, having an actual example of data in front of you, instead of only definition of the structure/schema/interface/type of the data could push people more towards relying on things specific to that example. Especially in dynamically typed languages, but also for things like trying to take the first element of a list that might be empty (in languages where that doesn't return an `Option`), etc.
And I wonder whether someone observed that in practice.
