ignorabilis

How so? You work with Clojure or CL?

Experience is just data. So one day when you go to Everest hiring a sherpa might not be needed. Why? Because a simulator can be created, based on his knowledge and all the other knowledge about Everest.

Regarding your other questions: Humans will build the machines that build the machines. In fact they do it now. Then we will build machines that can build machines based only on a design. That's the future.

The thing with the machines is a little bit different, but essentially it is much better to work from an office 2-4 hours a day, controlling a mining machine compared to actually mining.

Once a person can read there is almost no need for anyone else to teach him anything. I never listened in class, didn't have a notebook and got A's when I wanted to. I was reading the books that we were supposed to, but I prefered to explore them my way and I usually read them before it was needed. I know other people like me. I also know that people are curious in general and like to explore if given the opportunity.

And here comes my last answer - these people will do that because they want to see the result. Because they will enjoy doing it. And when they no longer find it interesting they will move on to something else. Because not doing anything is depressing. Doing it against your will - even more.

I think this is pretty amazing - in my own country we have a town - Dimitrovgrad - built completely from scratch and only after that populated.

For me it is anything that helps me not fix on the problem. Standing in front of the computer, staring at the code always pushes me in the same direction; once I am up to something else, but still 'lightly' thinking about the problem I come up with better solutions. It's almost as if I am thinking about it I can't think of anything valuable; once I stop thinking about the issue at hand everything just happens to fall in place.

Parenthesis in Lisp are not more than those in C. It's just that there is only one type of parenthesis and the accepted convention is to pile all the closing ones at the last line. When you have some time play with them in both C and Lisp and count them.

Actually the OP uses Clojure in his project.

In OOP everything happens somewhere else because there's always another layer of indirection, and so the code that should change the variable isn't in the function (or file) that you're reading. - and because of that when you are debugging it may change right under your nose, with no code obviously responsible for that. There is a nuance, but the idea is the same - only the context is different. It's just that when you are debugging it hurts the most.

In the context of the article I/O is someone else's code. If it were my code it should be tested elsewhere, as if someone else wrote it. Not in every place that my application uses it.

In the particular case with writing the actual I/O code - I don't have enough experience, so I can't tell you. Maybe tests are absolutely necessary. Maybe mocks are the only way. I don't know.

What I do know is that programs transform input to output - input -> transformations -> output. You never care where the input comes from nor where the result of your transformations go. All you care is if your transformations are correct.

Your program may be very complex, with many inputs that you don't control, scattered around your logic. So prior to writing tests you have to decouple those dependencies from your logic and only then proceed with writing tests. If you are using functional language you may reduce every piece of logic to the simplest, smallest function possible, test it in the REPL, document it and move on without actually writing tests.

As long as there is some sort of logic tests can be written. The question is can we prevent writing tests at all by designing better our applications and by taking advantage of FP languages and tools like the REPL? And I believe at least in theory we can. In practice life happens so this theory is certainly not applicable to every case on the planet.

When things are decoupled refactoring is not that dangerous. If all pieces of your program are small, intelligible functions you can always just refactor a single, simple function and you should not need tests to rely on - all you have to do is make sure that this function is working like it worked before the refactoring (or better).

Well, to be honest I didn't. I just started dedicating my time and efforts only for a few select people that are worth it. Otherwise social interaction can be too tiring and even lead to depression. Empty conversations, not loneliness, are what I hate the most.

You don't need to mock it. In your tests just manually call the code that is going to be executed if the I/O call returns an error. This goes for both OOP and FP.

I/O is someone else's code, not yours. So it's someone else's responsibility to test it. You should just test the arguments that you pass (in case they are generated) and trust that the I/O is properly tested by its author.

In OOP everything happens somewhere else because anything can hold a reference to the variable and change its value right under your nose.

To me at least these are two different concepts.