Conversational interfaces are a bit of a meme. Every couple of years a shiny new AI development emerges and people in tech go "This is it! The next computing paradigm is here! We'll only use natural language going forward!". But then nothing actually changes and we continue using computers the way w
Every couple of years a shiny new AI development emerges and people in tech go “This is it! The next computing paradigm is here! We’ll only use natural language going forward!”. But then nothing actually changes and we continue using computers the way we always have, until the debate resurfaces a few years later.
Reminds me a bit of graphical programming. Every couple of years someone comes up with the idea of replacing textual programming with some kind of graphical interface with arrows between nested boxed of various shapes and it inevitably fails.
Except there’s Simulink, which has been around since the 80’s, and is anything but a failure. For a few specific usecases, like modeling complex physical systems and developing control algorithms for them, it’s far better than any traditional text based language. Especially when it comes to maintainability of that code.
Though I have to admit that if you try to use it as a general programming language, you’ll learn that while that’s possible, it’s also very painfull. And even while implementing said control algorithms you’ll occasionally run on to some bits of logic that prove to be annoyingly difficult to implement with it compared to any text based language.
I think the problem is that you can’t create new abstractions very well in graphical languages. It works for something like fixed domains (e.g. Blender node editor or your example) but for a general purpose language you need the ability to define abstractions that never existed before.
The other problem is that you can’t really apply any of the tooling to it that works with other languages, e.g. version control, formatters, linters,…
I have to agree. I guess the only reasonable application for graphical languages is domain specific languages, and even then they need to provide a significant benefit over any text based alternative to outweight the tooling incompatibilities you mentioned.
Reminds me a bit of graphical programming. Every couple of years someone comes up with the idea of replacing textual programming with some kind of graphical interface with arrows between nested boxed of various shapes and it inevitably fails.
Except there’s Simulink, which has been around since the 80’s, and is anything but a failure. For a few specific usecases, like modeling complex physical systems and developing control algorithms for them, it’s far better than any traditional text based language. Especially when it comes to maintainability of that code.
Though I have to admit that if you try to use it as a general programming language, you’ll learn that while that’s possible, it’s also very painfull. And even while implementing said control algorithms you’ll occasionally run on to some bits of logic that prove to be annoyingly difficult to implement with it compared to any text based language.
I think the problem is that you can’t create new abstractions very well in graphical languages. It works for something like fixed domains (e.g. Blender node editor or your example) but for a general purpose language you need the ability to define abstractions that never existed before.
The other problem is that you can’t really apply any of the tooling to it that works with other languages, e.g. version control, formatters, linters,…
I have to agree. I guess the only reasonable application for graphical languages is domain specific languages, and even then they need to provide a significant benefit over any text based alternative to outweight the tooling incompatibilities you mentioned.