I would like an IDE that saves files in a consistent format but displays the code in whatever style the user prefers. This shouldn’t be hard to do and would help version control a lot.
Features I'd like to see in future IDEs
21–30 of 59 posts
Re: Features I'd like to see in future IDEs
#22What I'd really like is an IDE that functions on objects of code and not text files, and diffs and merges thar similarly operate on the syntax tree of the code and not on whether there's an extra newline or not. Like, code formatting, that's just an implementation detail. Why can't there be a thing to let two people edit the same repo with different formatting preferences without it causing merge conflicts?
related to this: I want structural editing for non-lisp languages so I don't have to deal with measly lines of code, but with entire trees and branches.
something like this for Python: https://shaunlebron.github.io/parinfer/
Re: Features I'd like to see in future IDEs
#23I would like an IDE that saves files in a consistent format but displays the code in whatever style the user prefers. This shouldn’t be hard to do and would help version control a lot.
I have been thinking about this for ages.
There's no reason we even have to work on "files". An IDE should be able to show you a module, or function, or call tree, or data dependency graph, anything!
There's so much to be improved in this area.
The only feature in this dimension I've seen is jetbrains injected language editor, where you can edit a string as it's own language thingy.
Re: Features I'd like to see in future IDEs
#24I would like an IDE that saves files in a consistent format but displays the code in whatever style the user prefers. This shouldn’t be hard to do and would help version control a lot.
Can you elaborate?
Mature IDE's already customize the presentation of things like annotations or comments, inject inline hints, and provide alternate editors for things like XML, markdown, or established UI description formats, etc
Re: Features I'd like to see in future IDEs
#25What I'd really like is an IDE that functions on objects of code and not text files, and diffs and merges thar similarly operate on the syntax tree of the code and not on whether there's an extra newline or not. Like, code formatting, that's just an implementation detail. Why can't there be a thing to let two people edit the same repo with different formatting preferences without it causing merge conflicts?
I feel that the problem is not text but language design. A great language should be close to a pareto optimum for both human and machine legibility. Most languages are optimized for human familiarity, which is definitely not the most machine readable format and probably not the most human readable (in a platonic sense).
Being more specific, most languages, in my opinion, are far too permissive with whitespace and use too many keywords. The former leads to there being no canonical form of the program text and results in reliance on external formatting tools, when the compiler could be just automatically enforcing canonical formatting rules. The latter makes it hard to distinguish between types of words, which is why it is almost necessary to rely on syntax highlighting.
If each program has a unique canonical form, it would be very hard to beat text based diffing on that form. Lisp is quite good from the diffing perspective but weaker on human legibility (for most humans).
Re: Features I'd like to see in future IDEs
#26After three decades in software development I can happily say that I can’t remember the last time I was stuck chasing data in some abstraction hellhole. It’ll never seize to amaze me just how much self-flagellation OOP enjoyers are willing to endure. I’m not sure I’ve ever even seen an abstraction chain go as deep aw the example in the article. Maybe in one of the projects I sometimes review when I do my side gig as…
It seems you have a very different idea of what abstractions are than I.
Abstractions as i know them are everywhere. Even little kids use them all the time. Grouping 7 digits and tagging them with the type "phone number", "number" or even "set" is an act of abstraction.
Any type of data that you want to represent anything, needs a structure. Structures are abstractions.
That said, i find using prints as a debugging tool often very handy. Especially when you want to see the effective order and nesting of sequences (for example communication protocols in action)
Re: Features I'd like to see in future IDEs
#27All of these are things he can find using a better IDE. No new or breakthrough we need for the next generations of IDEs.
Re: Features I'd like to see in future IDEs
#28I was thinking about the commit mask thing recently but imagining it as a part of Git, or an extension.The project I'm on at the moment is a big legacy codebase that requires a bunch of dev-only code changes for:
- functionality (setting API urls; forcing certain screens to appear; overriding config values that come back from an XHR)
- quality of life (skipping delays; turning sounds off)
It would be great to be able to toggle and mix and match these patches locally without risking committing them. A combination of stashes and branches kind of works, but the ergonomics isn't great, especially when there are conflicts.
Re: Features I'd like to see in future IDEs
#29Future IDEs will be IDEs that (will try to) understand what the code and developer is trying to do. Clippy, but more like a smart and fast butler who only needs half a word to understand where you want to go.
My feeling is that such feature will whipe away a big chunk of existing and today's desired features.
Re: Features I'd like to see in future IDEs
#30Emacs already let's you embed images in comments with iimage-mode