Over 10 years ago, I had this sort of a prediction that, with the massive adoption of a dynamic language like javascript on both client/server sides and test-driven development gaining a lot of ground, the future of programming would be dynamic and “feedback-driven”. As in, you would immediately see the results of your code as you type, based on the tests you created. To naively simplify, imagine a split screen of your code editor and a console view showing relevant watch expressions from the code you’re typing.

Instead what happened was the industry’s focus shifted to type safety and smart compilers, and I followed along. I’m just not smart enough to question where the whole industry was heading. And my speck of imagination on how coding would have looked like in the future wasn’t completely thought out. It was just that, a speck of imagination that occurred to me as I was debugging something tedious.

Now, most of the programming language world, seem to be focusing on smarter compilers. But is there some language or platform, that focus instead on a different kind of programming paradigm (not sort of OOP, FP paradigm, may be call it the programming workflow paradigm?). May be it comes with a really strong debugger tooling that’s constantly giving you feedback on what your code is actually doing. Think REPL on steroids. I can imagine there would be challenges with parsing/evaluating incomplete code syntax and functions. So I guess, the whole compiler/translator side has to be thought out from the ground up as well.

Disclaimer: There’s a good chance I simply don’t know what I’m talking about because I’m no language designer or even close to understanding how programming languages and it’s ecosystems are created. Just sharing some thoughts I had as a junior dev back in the day.

  • Phoenix3875@lemmy.worldEnglish
    3·
    1 year ago

    Thank you for raising the question. I think it’s an important one to think about. I constantly hear about good things about the REPL experience of LISP family languages. You can set up a code fragment (the test in your example) to run constantly in the background as you edit. Then you can jump to the REPL anytime and interact with the state.

    I myself am more on the ML-family side of FP, where you’d encode the expected behavior with an expressive type system and work with the type checker (the smart compiler) to implement that behavior.

    One important thing to note is that the type checking process is also a fast feedback loop. The difference is that it’s often on the abstract level and you’re more concerned about the expected behavior instead of the actual behavior.

    It’s harder to write, but the advantage is that you’ll have more confidence once it type checks.

    Of course, the two styles are not mutual exclusive, just that the tooling ecosystem will often reflect the culture of that language family. And it’s easier to add a simple watch make task, but harder to go the other way around.