Bit of a side issue for me: I was working on my Unity game the other day and thought to myself, have IDE's really not progressed all that much in the last 10-20 years?
Default intellisense has definitely gotten a lot better, but apart from that and a few other minor things the whole concept of coding feels pretty much the same today as back then.
The biggest positive change for me is outside of the editor, it has become easier thanks to much more access to libraries, documentation and just the sheer volume of user questions and answer sets we now have access to (and finally some new tools like ChatGPT that can aggregate those answers to on occasion deliver a reasonable answer).
But overall the act of writing code seems to be stuck. As a result I'm currently taking some time out from my game to run some experiments. I don't want to create a new language, but instead I want to try and offload everything I can to the computer, let it do the drudge work while allowing me to create.
Just 3 of the initial things I want to test:
- Why do I need to worry about small language specifics like brackets, terminators and so on when tools should be able to auto-complete them for me? What about the private-public access chain (as well as other modifiers such as unsafe) when tools can auto-determine the most efficient set?
- You're editing a file (or parts of different files) and are focusing on say 5 methods that are interacting. I want to see all of them on the screen at the same time, without having to struggle to open and manage many windows with for example VS horizontal/vertical sliders.
- Data conversion. So I created a HashSet for something but realize I need to change it to a Dictionary or a Tuple, just make it happen. If it requires brainwork then show me all the places that requires supervision where I have to say ok or make an edit myself. In the case of Unity I also want to be able to click on a method and/or data set and tell it to convert it to a Burst Job with its accompanying NativeData sets.
> The whole concept of coding feels pretty much the same today as back then.
The whole concept of programming languages has not changed that much. We have the two big pillars that is the Turing Machine and Lambda Calculus (and various others) Everything after that has been abstractions, and when the abstractions are good, we call them paradigms. But it's all abstractions, and ultimately we are just writing instructions for a really dumb machine to compute data for us.
> Why do I need to worry about small language specifics like brackets, terminators and so on when tools should be able to auto-complete them for me?
Because the computer is something really simple, and the programming language is just a idea conduit from your mind. Those delimiters are as important as the language keywords, because they are part of the RULES. Auto-completing them will require more RULES and more delimiters.
> You're editing a file (or parts of different files) and are focusing on say 5 methods that are interacting. I want to see all of them on the screen at the same time
Vim and Emacs. Or Smalltalk IDEs like Pharo
> Data conversion
Vim and Emacs macros. But the truth is data encodings are very important, because for the computer, it's all bits, we assigned meanings to these bits and enacted RULES that describes how to manipulate them according to these meanings. Morphing from a set of RULES to another will require more RULES.
I will urge you to try a live programming environment (SLIME for Common Lisp, Pharo for Smalltalk, The web inspector for Javascript (not great)). It feels like working on a boat in the middle of the sea instead of having it on land imagining what it feels to sail it.
Slime or Slimv with a file/buffer as the REPL input it's one of the best things ever.
Refactor your code doing crazy data mangling on functons? On Lisp you just redefine functions/macros with ease. With the rest of languages the complexity raises exponentially.
It is, but not directly. The practice of working directly on canonical plaintext representation is what's bottlenecking programming.
At any given moment, the programmer cares about different aspects of code. One moment, they're trying to correctly structure an abstraction layer; an hour later, they may be debugging an issue that needs them to walk up and down the abstraction ladder several times. One moment, they need to understand the data flow on success path; the other, modify the overall parallelism characteristics of the program.
Cramming all these conflicting requirements and cross-cutting concerns into the same files, to be read and written directly, is what's bottlenecking us. That's why we have never-ending holy wars on what is "clean code", why our editors work on such low conceptual level, why we get languages like Haskell or Rust, packed with cutting-edge math research output. We're hitting a Pareto frontier - trying to make some things more readable and explicit makes other things harder.
The solution is to stop working on code files directly, and let software synthesize views amd editing interfaces - textual and graphical - on demand. Many perspectives on the same underlying artifact, that itself will not need to be optimized for human consumption.
And Emacs and VIM already have all the bits for improving your experience, but you have to integrate them yourselves. Or get an IDE that does it for the language you use. What you need to do is develop your own meta-language to shorten the time between idea and execution. Snippets, code generation, auto-completion, code analysis and navigation, all help.
I agree about auto-complete, but already the editor Brief for MS-DOS, at least some 35 years ago, allowed you to define arbitrary templates for auto-completion.
For example, when writing a C program you could choose to have "f<TAB>" expanded to "for (=; <=; ++) {<LF><TAB>;<LF>}<LF>" or whatever indentation you preferred.
There are many modern programming editors that allow a similar customization, though unfortunately for many of them this requires a more complicated procedure than in the far past.
For any programming language with a verbose syntax, I consider necessary to take your time and define in your editor templates that would allow the fast writing of any program structure with a minimum number of key presses.
I may not be understanding you correctly, so please let me know if I've gotten it wrong.
Some of the stuff you're talking about -- like brackets and terminators -- make explicit the syntax and greatly improve tooling. Usually editors have features that can add these in or you. But in some cases something is obvious to you, but is really one valid choice among many and the tooling can't read your mind without something like a design doc to guide its decisions.
For others -- like whether to use a HashSet or Dictionary or Tuple -- those have performance implications and it's not always clear in the abstract when to use one or the other. But for explicit languages like Java (and I would assume C#) you should be able to refactor a method call to take a different type. Then you just have to change one method and refactor all the calls to it.
I've been experimenting with the pro Gemini and ChatGPT o1. They're both really bad at coding Python and JavaScript. They write buggy code and will often introduce bugs when attempting to fix another. Both feel like they're rushing to answer instead of thinking about the requirements. I'd say we're still a bit away from having tools that can "read your mind" or understand what matters to you and what doesn't the way you'd (or we'd) like them to.
Potentially even worse: consider the data we're training on. These tools will be adopting the thought patterns of the average coder since most code is produced by average and below average coders. Even if we trained the tools only on the highest quality code, it's not clear that most coders would know how to prompt it correctly. So I think if you've been coding for 10-20 years chances are decent that you'll always be a little disappointed with the tooling if you're expecting instant wizardry.
That said, non-AI static analysis tools have been great for a while and will get even better. Adding AI to them will improve them further. So I think you can have a great experience if you're thinking of the tools as helping you be an artist rather than as an artist you can give a spec to and get back a decent result.
EDIT: It might be fun to experiment with telling the AI what you want your editor to do more of and asking the AI to help you configure it. There's a lot of non-AI tooling in plugins. Getting an LLM to help you pick the right plugins for your lifestyle may be the best bang for your buck.
Yeah I've also been playing with ChatGPT etc. and sometimes they can produce great code, or at least get you up to speed a lot faster. As long as you ask them questions about well known problems they're great, but break down after that. But they're definitely going to play more and more of a role going forward.
What I really want to explore (and where I think there might be some big room for improvement) are around how we represent and visualize both code and data, as well as how we interact with it. Full visual programming has often been tried before and while it works fine for a while it begins to break down once projects become more complicated.
I instead want to explore some alternate text based options where we use the visual aspect as an assistant, whether by grouping or collating blocks that we're working on, changes that needs to be made and so forth.
I'm mildly skeptical of visual programming because code generally won't be a planar graph and it's rarely useful to visualize a complicated enough graph. You can try to embed the graph in hyperbolic space, but I'm not sure how much you get out of it. For example of visualizing a graph where it's not clear what's going on: https://cambridge-intelligence.com/wp-content/uploads/2021/0...
Coding is a logic/language type activity that uses the language parts of your brain. Visualization can help see that certain relationships are true (e.g. visualizing the graph of a function), but I think the fundamental bottleneck we're dealing with here the inadequacies of the visual regions of the brain to do logic, not a lack of AI tooling.
I'd be happy to have my mind changed though.
EDIT: Although, an AI version of something like Chernoff Faces for visualizing data would be cool.
> You're editing a file (or parts of different files) and are focusing on say 5 methods that are interacting. I want to see all of them on the screen at the same time, without having to struggle to open and manage many windows with for example VS horizontal/vertical sliders
Regarding this, maybe haystack could be interesting for you
This looks awesome, any users out there that can opine?
Not sure this is the answer but for sure this is highlighting the right question. I’ve never been a teacher, but having been involved in mentoring newbies more often than I expected.. error traces with absolute filenames and terminals with Click-to-edit-file support are the smallest effort you can put in to get the biggest results (although this can also lead to confusion with virtual envs and such).
That’s just the beginning of the nav we really want though. The key point is all about focusing on “don’t make me mess with file systems” because the code already has many dimensions of inherent structure.
Some of what you described, having 5 methods on screen, or finding all locations failing type checking, I have been using (neo)vim for successful over many years.
I load the output of the type checker (or compiler) into vim. I then have a list of locations to inspect. I can move between the locations. I can open multiple locations (same file or not) at once on the screen. Nowadays, Copilot assists in the refactoring besides the usual vim commands/regex/macro.
Opening 5 pane for 5 methods is similarly easy. I can also use a side panel to quickly view all methods and jump between them in addition to the traditional vim motions.
Language servers (LSP) of course makes the whole experience delightful. Jumping and navigating around the code etc.
All of that is keyboard driven, with many keyboard shortcuts personalized to my liking.
Here is an example of my workflow. I run the compile/typecheck command in a terminal, via a script that runs the command as soon as a source file has changed. It also saves the output into a file at a standard location. Saving in vim triggers the command to re-run. Then a key press reloads the output of the command to quickly jump around.
And navigating and modifying brackets is trivial in vim, especially with the right extension. Auto inserting brackets, I never found a plugin that I liked enough yet.
It's not all nor exactly what you asked for. But it's something.
I think one of the main improvements we've - interestingly - been unable to widely adopt is an actual live programming environment. Smalltalk was this. Nowadays I mainly use Common Lisp for something reasonably close.
We're still mostly stuck in an edit->compile->test cycle. Stuff like TDD and debuggers help here, but considering the untapped potential for what programming environments could be, it seems to me like we're stuck on a local maximum.
Edit: Don't get me wrong, programming in Smalltalk didn't seem entirely pragmatic to me. Reproducibility becomes something you need to actively worry about, with popular tech stacks it's kinda built in. My point is the potential of such approaches, not the pragmatic viability of the implementations we've had so far.
> You're editing a file (or parts of different files) and are focusing on say 5 methods that are interacting. I want to see all of them on the screen at the same time, without having to struggle to open and manage many windows with for example VS horizontal/vertical sliders.
I think that is, why editors like emacs and vi are really popular.
- Data conversion. So I created a HashSet for something but realize I need to change it to a Dictionary or a Tuple, just make it happen. If it requires brainwork then show me all the places that requires supervision where I have to say ok or make an edit myself.
How different would that be from changing the type and editing all the places the compiler complains about?
>How different would that be from changing the type and editing all the places the compiler complains about?
Currently in VS if let's say I change the Set to a Dictionary it will compile in the background and then complain about all the errors from where I can click on them to be taken there, and/or I would search on the variable name and find all the references and just scan through all of them to make changes as necessary.
Some ideas there could be:
a) We can use multiple windows (or lines in 1 window) to just quickly display all of the required changes directly on screen without me having to manually go from one to the next.
b) Let's say we were doing a standard List.Add but now its a Weird.Blob (ie. a non-standard class with no built in conversion support). I can perform a replace all .Add with .Blob which text editors can already do, but what if we only applied it to this current set of windows that have opened up, so as to not break other things? Again you could have done that with a narrower replace, but this way might be easier or faster.
c) In text editing you might have to replace a few lines several times, so you'd copy the new line or a segment of it, then replace all the parts of the old instances. What if we sorted all those opened windows so that the ones that are most similar are located next to each other, then if we change one we just drag it (or parts of it) to the other windows to make replacements. If they are exactly the same then provisionally change them automatically, the user just accepts the whole block of changes (as if they had done a search/replace for a specific line, or part of a line).
When it comes to writing code being stuck in time, I'm expecting that LLMs replace programming languages rather than programmers. We aren't there yet and LLMs, or the next iteration of architecture, need to get better at logically working through and validating code, but I do think we'll get there.
When you think about it, its really pretty ridiculous that a programmer will ask an LLM to write code that the programmer can copy and ultimately compile into machine code for yet another computer to use. Cutting out the intermediary steps seems like a logical next step.
About the first item on your wishlist: If by "brackets" you mean {} (in C-like languages), there are IDEs that can be configured to create pairs of them every time you hit return after an expression that can take them. The downside (if you care) is that, if you wanted to write an if, while, or for with only one line, and therefore no scope delimiters, it will force you to create the scope anyway. You may not care.
If by "brackets", you mean [], to access an element of an array or vector or map or whatever, yes, it could do that as soon as you gave it the name of an array or vector or map or whatever. But then if you wanted to deal with the array or vector or map as a whole (which you want to do sometimes), the brackets have to go. I would estimate that 30% of the time I want to deal with the array as a whole, so such a feature would be annoying and in my way 1/3 of the time.
Terminators are a win more of the time. But when they're not, I meant to be continuing one line of code across two lines of file. If it auto-added a terminator (semicolon, say) at the end of the first line as it opened the second, I might not even notice until compile time. That would be highly annoying.
Public and private I don't want determined by a tool auto-determining the "most efficient" set. I want them determined by my sense of what the class is, and therefore what the public interface should be. Some of the things that are private are less efficient, but are private because they're implementation details and I don't want callers able to fiddle with them.
So, that's my whiny personal take on some things on your list. Maybe I've adapted myself to the existing tools. But I personally think that many of your items, if you implement them, you will find that you don't really like how they work out.
Yeah some of my points are really space dependent. For example I'm working on a solo game project, so my comment on the public/private etc. modifiers is really aimed at that where nothing will ever be exposed and the modifiers are pretty much irrelevant.
>So, that's my whiny personal take on some things on your list. Maybe I've adapted myself to the existing tools. But I personally think that many of your items, if you implement them, you will find that you don't really like how they work out.
You could very well be 100% correct there. As developers we really become used to our tools and its quite hard to adapt to new ways of doing things. But I figure its worth a shot, at the worst I'll have learned a few things along the way.
Verified pre and post conditions would be nice. Especially in the era of LLM's, which can usually fill in the implementation given a sufficiently clear specification.
What's the problem? Golang is more than a decade old. Python predates Linux. Common Lisp with ANSI C is from early 90's too, but it began as Lisp in the 50's.
"Why do I need to worry about small language specifics like brackets, terminators and so on when tools should be able to auto-complete them for me?"
Actually, if you are using an IDE, there's probably a flag you can flip for that. It's a very common feature, to the point that I often find it in places I'm not expecting, like the web-based security training code platform my employer periodically pushes us through.
I'm not a fan, but some of it is just that my habits haven't developed around it.
There have been a number of tries at going even deeper, and trying to make it so the code is valid at all times. I suspect this one fails because we pass through more invalid states than people realize. For instance it's not uncommon for me to copy & paste some data from somewhere to embed into a program, and to massage it in my code editor until it is valid syntax, but it isn't "valid" until the very end. Smaller scale things like this happen all the time. It is more constricting than I think people generally realize to have to be valid every second.
"You're editing a file (or parts of different files) and are focusing on say 5 methods that are interacting. I want to see all of them on the screen at the same time, without having to struggle to open and manage many windows with for example VS horizontal/vertical sliders."
We've tried that already... and actually I'm with you, it's awesome. I suspect this is just because by the time you've got all the other IDE gizmos on the screen it's hard to do too much splitting. But my normal code setup is three emacs windows side-by-side on the screen (and, that is, windows, managed by the windowing system, not "frames" within emacs), each of which then can and often are further split once vertically. If I have to go all the way up to truly using 6 contexts at a time, something has probably gone wrong architecturally, but 2 is extremely common and bursts up to 3 and 4 a daily occurrence.
Watching some people recently trying to get into a largish code base, and watching them interact with it basically through a single window and at times not even with an IDE, really makes me think one of the larger problems is people learning how to "turn the lights on" in a code base. It isn't even a matter of implementing features at this point, honestly almost any environment already has a ton. You need to learn to use them.
"Data conversion. So I created a HashSet for something but realize I need to change it to a Dictionary or a Tuple, just make it happen."
We tried that already... and it comes with some substantial costs you may not realize.
First there's the obvious performance one. Make it easy to auto-convert them back and forth without any syntax fuss and you'll end up people writing loops in which the 1,000,000-million element hash table is converted both back and forth between a hash table and a tuple list in a loop, once per element, and you end up with the sort of bloated programs we all like to complain about. (Indeed, this sort of thing is one of the root causes, though far from the only one.)
The more subtle one is that automatic coercion, of which this is an example, is just generally a bad idea. The programmer ends up with a too-fuzzy idea of what is going on, and that fuzziness manifests not just in the aforementioned performance issue, but also, bugs, when it turns out that the properties of various structures being autoconverted back and forth are actually important to the code. The most common example which is increasingly widely regarded as a bad idea is "falsiness", where the language tries really hard to have a concept of true or false for all sorts of data structures, but the bugs that emerge from empty strings being read as false unexpectedly and such make this generally not worth it. In the case you cite, the data structures are not the same; they differ substantially in what they do with multiple values for a given key, and how order-sensitive they are, and in the world of programming, these details all matter. Especially because they end up being used to construct security systems.
It is hard to see the general sweep of programming language development, but in general at the moment I think languages are headed away from auto-conversion. What you can see is languages and libraries developing better "interface"-like abilities, where maybe they can declare that they just need this or that bit, and then you can pass multiple different structures in. See for instance __getitem__ in Python. This is a much better approach; there's still some fuzziness cost but the offsetting benefits are much stronger so it's a much better trade.
Some good feedback here and in the thread overall.
I also use a 3-way horizontal split these days for editing, I've found that the wider our screens get the less I use the edges. So now often I'll keep the left focused on the headers to variable definition, the middle for the main editor and the right for methods where the middle is calling or being called by something.
In Visual Studio you don't have to dock windows, but the current generation of floating window doesn't really conform to what I want. Someone else mentioned Haystack which I haven't seen before:
https://haystackeditor.com/
I quite like the layout of Haystack, although I don't think one wants to take it too far such that it begins to resemble visual scripting. I think a block based approach where you have different blocks for the different types such as classes, variables and code might be worth exploring.
I'll definitely post back sometime with feedback on whether I've come up with anything interesting.
I hope you do. I know it's easy to just crap on someone's ideas, but I'm really trying not to do that. I think it's a great idea to learn from what came before, because if anything's going to succeed it is almost certainly going to be at least a little different than what someone else tried. Sometimes it can be the smallest difference that decides the matter. I wish you the best of luck in your explorations.
Visual Basic in VS has aggressive autocomplete and it gets pretty annoying. You often want to write things in a different order and end up having to delete the auto-inserted endif/quotes/brackets/variable names (if it's not yet declared, it changes it to become something else that is), etc.
Default intellisense has definitely gotten a lot better, but apart from that and a few other minor things the whole concept of coding feels pretty much the same today as back then.
The biggest positive change for me is outside of the editor, it has become easier thanks to much more access to libraries, documentation and just the sheer volume of user questions and answer sets we now have access to (and finally some new tools like ChatGPT that can aggregate those answers to on occasion deliver a reasonable answer).
But overall the act of writing code seems to be stuck. As a result I'm currently taking some time out from my game to run some experiments. I don't want to create a new language, but instead I want to try and offload everything I can to the computer, let it do the drudge work while allowing me to create.
Just 3 of the initial things I want to test: - Why do I need to worry about small language specifics like brackets, terminators and so on when tools should be able to auto-complete them for me? What about the private-public access chain (as well as other modifiers such as unsafe) when tools can auto-determine the most efficient set? - You're editing a file (or parts of different files) and are focusing on say 5 methods that are interacting. I want to see all of them on the screen at the same time, without having to struggle to open and manage many windows with for example VS horizontal/vertical sliders. - Data conversion. So I created a HashSet for something but realize I need to change it to a Dictionary or a Tuple, just make it happen. If it requires brainwork then show me all the places that requires supervision where I have to say ok or make an edit myself. In the case of Unity I also want to be able to click on a method and/or data set and tell it to convert it to a Burst Job with its accompanying NativeData sets.