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.

  • MagicShel@programming.dev
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    The main issue I have with this is the exclusive focus on happy path. The point of unit tests and especially mutation testing is to validate that every code path has a defined test and hence defined behavior. I wouldn’t want to give that up, myself. I’m a huge believer in type safety and immutable objects and other things that prevent architectural misuse.

    • nayminlwin@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I’d imagine there would be no need to give up type safety, unit testing and all that though. I’m thinking more about language and tool creators’ focus and efforts going mostly into compiler and type safety.

      • MagicShel@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        I’ve seen live updates for things like Go, NodeJS, Vue, Flutter, Angular, and you can recompile a Java class during debugging in Java (with limitations as certain things like static variables and methods need a full restart). More support and integration is certainly better but it doesn’t feel like it’s in a bad place to me.

        • nayminlwin@lemmy.mlOP
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          I wouldn’t say it’s in a bad place either. Most enterprise grade technologies already have great debugging tools. Sure, those hot reloads, live updates are nice for UI development. But, I was thinking more of something built from the ground up to be, well, “feedback driven” in general. Most new stuffs that came out in the last decade touted their compiler as a killer feature first and rest of the tools are only developed as the ecosystem mature. May be that’s just the best way to go about creating new successful language ecosystems, I don’t know. Sorry if it feels like I’m being vague about the specifics. That’s because I really only have vague ideas about whole the whole thing would work.

    • russ@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Just to share a perspective from erlang/elixir: pattern matching to filter for only happy-path inputs and the principle of “letting it fail” (when the inputs don’t match the expected shape) works really well in some paradigms (in this case, the actor model + OTP, erlang’s 9 9s of uptime, etc). In that kind of architecture you can really only care about the happy path, because the rest is malformed and can be thrown away without issue.