One person explains in the future, there'll be no need for programmers since AI will be able to generate the code which fulfills the program spec; the programmer replies "and what would you call someone who instructs the computer what program to write?".
It’s conceivable that in the future, coding will be so easy it won’t exist as a specialized job anymore. Consider how the web dev career of making websites for small local businesses has been substantially replaced by squarespace, which can be thought of as a tool for which the input is a very high level specification and the output is html/css/js/backend code. And the specification is high level enough that you can ask your mom to use it - it won’t shock me if we see this happen to more industries
It's possible, but I'm skeptical, because the hard part of coding isn't "typing words into a text editor/IDE." It's thinking algorithmically in enough detail, with edge cases, fallbacks, error handling, etc, that most people struggle with.
Squarespace is actually a good example; someone still has to write all the nifty widgets and figure out how they'll work together for a pleasing experience. If putting an attractive visual layer on top of code was all it took, then Smalltalk would have won decades ago and everyone would program.
The main barrier to "no code" and "everyone can program" is still the mode of thought, not the mode of representation.
This has parallels in artificial intelligence, where as soon as a problem is solvable by a computer, solving the problem no longer counts as "AI" (chess, natural language processing, even sentiment analysis!). Similarly, as soon as a problem is made easy and accessible to non-algorithmic thinks, programmer move on to the next thing that requires that mode of thought. Maybe we'll exhaust the problem space of potential programs someday, but I don't see any evidence for it.
> It's thinking algorithmically in enough detail, with edge cases, fallbacks, error handling, etc, that most people struggle with.
And this is why we need better languages, not better editors.
Python was the last real language to bring prepackaged solutions that are easy to use and cover (some) edge cases to reduce development overhead. Adding a use-specific framework, such as Django, often takes care of the remaining 80%.
I'd love to see a new language or framework that makes adding new features - not features that the framework devs created but rather real new features - easy to code would be a boon to development.
Tools like squarespace increase the pool of generic copy-cutter websites. They do not reduce the pool specialized, purpose-written websites, which still require a software developer.
In fact, by providing an entry point into an online presence, squarespace and other click-to-get-online products may actually increase the pool of businesses interested in migrating to a specialized, purpose-written website as they expand past the capabilities that squarespace offer them.
Notably, a large percentage of the users of squarespace were probably never going to hire a web developer for a website in the first place, as it has always been too expensive. Squarespace is its own market, with a very small impact on full-time web developers. A mom-and-pop shop can have a website now and no web developer lost their job because of that.
Speaking as a web developer, the need seems to be increasing despite the plethora of available no-code tools. Meanwhile, no-code websites seem to be locking people out of their walled gardens evermore (Facebook Groups is horrid)
Websites and generic CRUD apps are domains that are very well understood, hence easy to automate when you don't have special needs. But high level specifications will not suffice as soon as the domain is less clear, less well understood, and/or less static. In fact, a sizeable part of software developers' jobs is to clarify ambiguous/unclear/contraddicting requirements coming from from business analysts and project managers.
So yes, easy stuff will be automated, as in many other industries, but this will create new possibilities that only specialized developers will be able to pursue.
The perfect editor is when your editing happens within the runtime environment, giving you ultimate feedback speed.
Common lisp's REPL come closest to mind. Erlang's hot swapping is the dopplerganger in deployment world. Bret Victor's inventing by principle is a good analogue to UI programming imo. Imagine editing CSS in browser's inspector, and have the change reflected back to source code. No more switching between editor(IDE) and runtime(browser). I heard smalltalk provide similar development experience, but I had no experience on it yet
> Imagine editing CSS in browser's inspector, and have the change reflected back to source code
There are browser addons that auto-reload a page making your changes visible every few seconds. You can tweak them to reload every 5 seconds or even every minute, depending on how fast you're building the site.
Better still, look at LiveReload which will monitor your css and image files during development and will automatically update the page without a refresh.
Typically I have two panes side-by-side. Typically Notepad++ and then a browser window with the webpage I'm editing with LiveReload installed which checks for changes to CSS/JS/HTML. I love getting instant feedback for my code. Having to live in the 'black box' of an editor without instant feedback sounds like hell to me.
That works great for UI but what about backend networking stuff or even for macro like environments like scss, where you write code that writes code, how will you change the input based on the output?
I don't know enough on specific topic to comment. I think it is a spectrum of "speed/ease of feedback".
e.g.
- Smalltalk, https://squeak.org/
- Haskell, https://ihp.digitallyinduced.com/ for database schema
- In python, I use a vim plugin, where you can run highlighter code by pressing Ctrl+R. I forgot the plugin name
- If you use erlang, there is no need for the kubernetes
- Tiddlywiki, where the result of your editing changes the source code directly
In general I think a good development environment is close to either quine or isomorphism (code is data, data is code)
> ... but what about backend networking stuff or even for macro like environments like scss ...
For generated CSS I had Emacs configured to generate the CSS on change and automatically update the "cache buster" token (just to be safe). Clojure(Script) with figwheel takes care of updating the webapp (in dev) on every change in the CSS dir. Really no issue there: everything is instant.
Mun is a subset of Rust syntax which supports hot-reloading, I think that could be a good direction to enable this sort of thing for the most frequently-changing business logic.
Quirky as it is, I believe Terry Davis's TempleOS actually allowes REPL-style development in its C dialect (HolyC). I'm not sure how exactly it works, but it's able to compile and execute statements as you type them in.
You can already do that with a browser. They all still have “save web page”.
Perhaps you’re functionally fixed on the idea an editor has to be interacted with like a word processor?
It’s all electron state. The boundaries are just UI design.
There are drag and drop web app building tools that let you fine tune the code in an inspector window, and transpile to whatever.
Perhaps what you need is to simply change how you work.
Most contemporary business app building could be visual; I mean look at what experiences Unreal enables with their blueprints. If that coding model can result in AAA games, I don’t see why it can’t replace a whole lot of website building effort.
This stuff is possible. It’s just you have to work for the aristocrats or else.
> Or when I find a really nice Node.js library that Just Works™.
This happens to me all the time. Every day really, whenever I type `npm install` I'm just delighted by the results. Those node libraries just make my programming experience so smooth and carefree, just like Apple products.
This morning I did just that, and was greeted by a nasty error. The solution turned it into an incompatibility between requirements. Not that impressed.
"perfect" will vary from person to person, and depending on the job to be done. not all "editing code" is equal.
Emacs can be found all over the proposed spectrum here, because there's so many people have made it their perfect editor for their current circumstances, and shared the tweaks that made it so for them.
I'm sure the other "favorite editors" have similar, i'm just not speaking of them because I'm ignorant of how often they nail "perfect", myself.
As usual the "paradox" is in how we look at it, not the cold realities.
> "perfect" will vary from person to person, and depending on the job to be done.
That actually isn’t relevant here. This is a thought experiment about which heuristic should be used to determine the perfect editor. How to think about what the perfect editor even is.
Maybe you grip your knife one way and I another, but we may both agree that the perfect knife is the one that gets our cutting done the most quickly, or with the most precision, etc
I wish someone figured out how to reduce latency from keypress to screen.
Even the JetBrains with their "zero latency" editor is lagging like mad.
How come old underpowered computers worked perfectly whereas new beefy machines can't do such a task?
My "perfect" code editor is neovim with maybe a dozen or so plugins, primarily focused linting my code, less so on major interface changes (e.g. NERDTree)
Someone else's perfect code editor will be the flip side of that: an easy to use (perhaps via mouse) file tree, autocomplete with snippets, virtual text, etc.
Someone else will be in between.
You get the point, each option is not more or less effective as it comes down to the individual.
If we could create a editor so good that it can generate all you app in a couple minutes, it means the "editor" is a strong AI that can take vague, subjective descriptions an generate a working, correct program (like a programmer would do). If that's the case you don't need programmers anymore: just put the customer in front of the AI and let them design the software.
But them if you have such AI, every job would be obsolete.
Every DE has a code editor these days, GNOME has geany and KDE has Kate, and so on. Incidentally, marcan of asahi linux fame primarily uses Kate in his streams, and from what I've seen it's perfectly functional.
Let me know what you'd do in Notepad++ that Kate doesn't already do. I'll try to find it or file a feature request.
Kate is absolutely terrific, it sits perfectly between VIM in a terminal and JetBrains for an entire project, whether I'm editing code, personal notes, or prose.
My perfect (hypothetical) editor doesn't try to keep you "in" but it interacts with other tools supremely well. I can use it to find text, to mark or select it and then apply a great variety of tools to it. I might select text in another application and then find myself live-editing it in my editor so that I can always use my favorite tool no matter what the application might be.
It also expects interoperability from other tools - so there's no file load dialog or project files view because all you do is load up your operating system's file manager and drag and drop.
It, with other components, build up into what one might call an IDE and it's up to me to construct my custom tool from all the bits including the editor.
I don't really understand the semantic games played here.
If you want to interrogate the issue, you need strong upfront definitions: what is a code editor? I'd assume the thing that edits the code, but the problem is created by shifting the scope to "everything related to software development".
That's either out-of-scope for the problem, or you need to define the problem better.
There are also a few dubious distinctions e.g. what are the boundaries of the "editor" - you could create a singe app that spawned two windows, one for docs the other for code; or use two different apps with exactly the same UI - from UX perspective the technical distinctions aren't relevant.
The perfect code editor is speech-to-text plus AI, with a thick Vaporwarium™ layer that listens to the executive's stream of consciousness and spits out performant, sticky, yet bug-free apps in near real-time.
The first option assumes you want to do your job easily. The latter assumes you want to solve all your problems. I'd love to have the former editor when coding as a hobby (where writing the code is fun), and the latter when coding for work (where solving the problem gets me paid, no matter how I solve it).
The dilemma sounds convincing, since the author seems to suggest that there are two possibilities. But they fail to realize that the one where you spend 0% of time in there is no longer a code editor.
I think it's not a dilemma at all because the two goals are not even mutually exclusive:
- You want to spend 100% of your coding time in the editor
- You want your coding time to make up as little as possible (ideally 0%) of your total work time
Given that, the perfect code editor is obviously one that makes coding so easy and quick that it hardly takes any time and one that you do not have to leave for external information whenever you do use it.
One person explains in the future, there'll be no need for programmers since AI will be able to generate the code which fulfills the program spec; the programmer replies "and what would you call someone who instructs the computer what program to write?".