I'm not sure I buy his argument. I see many programmers who produce inferior code with an IDE and many programmers who produce excellent code with an IDE. I'm in the Java ecosystem, where IDEs are pretty much ubiquitous. But I've used plain editors in the past mostly for other languages.
All in all, I don't see the link between using an IDE or not and the quality of the outcome. But I do see the link between using an IDE and development speed, where refactoring is just so much faster and less error prone if you have a decent IDE.
I haven't tried copilot yet, so can't say much about it.
He’s a really good programmer, but that’s not why his solutions were better. Since he didn’t have suggestions to guide him, he read the docs and by simply perusing them, was aware of methods and other features that the IDE did not suggest. There were better ways in the libraries they were using that weren’t apparent in the IDE. And that makes sense: in the interface for a suggestion in an editor, how much complexity can you really manage?
8x--------------
it makes sense to me - if the API is large and complex enough that you can discover good ways to do things via serendipity, IDE autosuggestions will stick you in a local maximum.
I usually format it this way. I like the scissors, though. Interesting.
> "He’s a really good programmer, but that’s not why his solutions were better. Since he didn’t have suggestions to guide him, he read the docs and by simply perusing them, was aware of methods and other features that the IDE did not suggest. There were better ways in the libraries they were using that weren’t apparent in the IDE. And that makes sense: in the interface for a suggestion in an editor, how much complexity can you really manage?"
It’s not mutually exclusive though right? For instance, google search has auto complete/recommendation to nearly any query. I use that when helpful and know when to ignore it as well and type in my entire query. (Genuinely curious as I don’t use these IDE features.)
no, not mutually exclusive, but the author had at least one anecdotal datapoint to suggest that people who relied on the IDE did not discover "unusual" functions that were better for the specific task
I'm using an IDE, but I read the docs anyway. I also just jump into the implementation and figure if the docs are correct. I don't know why the IDE should prevent anyone to do that. Again, it doesn't depend so much on the tool but more on the type of programmer you are.
I actually ran up against this exact problem of IDEs being ubiquitous in the JVM ecosystem at a previous job.
The company had just released a new SDK to access a data repository. Since it was a brand new library, they only had Java/Scala versions, with plans to support other languages (JS, Python being the next two on their roadmap) in the few quarters. My team, primarily researchers who only knew Python, needed to use some of this data for a new project. I figured, what the hell, I've been looking for an excuse to learn some Scala, I'll see if I can throw together a utility for my team to use to get access to this data sooner. I fired up Sublime Text and opened up the docs for the SDK and got to work. The documentation was terrible and I really struggled to do basic tasks with this SDK. Simple things like what types were expected for function parameters was just non-existent. Since this SDK was planned to be released publicly to customers, I thought I'd do my co-workers a favour and sent them a message with some feedback about places where I particularly struggled with understanding how to use their SDK, thinking I could help improve the documentation before this went out to paying customers. Their response was that if I just used a proper IDE for my development, I wouldn't have these problems since the code completion/suggestions would let me know what the types of parameters were.
That experience completely soured me on the JVM ecosystem and I walked away from learning it. When I finally came back two years later, I discovered that I actually really like working in Scala (admittedly I do use Intellij for it now), but that many library's documentation is still quite poor compared to what I've come to expect for Python libraries.
So full disclosure, I don't tend to write or read documentation that is external to the in-IDE documentation.
But why is documenting the types helpful? The IDE, and for Java/JVM there's a choice of multiple, will tell you. Why waste precious hours of life rewriting what is already documented in the type system?
Sure I'd document the why of something but the idea types should have any form of documentation external to an IDE that can parse the language just seems... redundant.
Whenever I hop over the fence to dynamic languages sure I have to read documentation and large amounts of it is rubbish that could just be inferred from source but that's why I don't hop over there often.
Docs are typically built from source on modern platforms. There's not reason to restrict type information to a particular set of tools when you are bothering to build documentation. Otherwise might as well save your time.
I mean, they have been 100% right. There is no point in writing down parameters types, because you see them in the IDE. That sort of docs is completely redundant.
I'm in the Java ecosystem, where IDEs are pretty much ubiquitous.
All in all, I don't see the link between using an IDE or not and the quality of the outcome.
That seems to be a pretty good link to me already...
I worked (briefly, fortunately) with Java for a short while a long time ago. The fact that even "small" Java projects are often ridiculously overengineered and so complex that an IDE is almost obligatory to work with the code in any meaningful way should itself be a sign of what dependence on IDEs tends to cause. The article mentions that too, and my experience agrees.
So you're thinking less of Java in general. I won't argue on that, because neither of us will change their mind.
But the author was basically saying that you can write better Java in an editor than if you were using an IDE. And this doesn't make sense to me. The code a skilled programmer will write with or without an IDE won't be that different.
Let's all just start writing code on a typewriter...
I remember the 90s IDEs. They were not fun. But still better than nothing!
Thanks to Copilot, etc bad programmers can now get a lot further, and perhaps it would be good for them to struggle so that they can become better, but don't lay bad code at the feet of an IDE.
> How much effort, in the non-mathematical sense, are you willing to expend to discover if there is a lower minimum? Go over the hill to your left and you discover a minimum that is greater than the one you were just in. Go over the hill to the right and you find a lower minimum.
> This happens in just about anything you can imagine, but let’s consider IDEs. You start using an IDE and it makes one particular thing particularly easy, and it makes it so easy that you don’t go looking for something even easier. You can’t spend all of your time wondering if there’s a slightly better way of doing things.
This argument resonates fairly well with me. I generally view IDEs as low commitment, a rapid learning curve to completion, with very hard caps on what you are going to find. You'll understand what the tool gives you, and then you'll be done. There's some trading/collecting hooks to keep you feeling like you can improve, to collect all the best plugins to improve the base system, but you're still a consumer, hunting for solutions, and you never really gain intimacy, understanding, or general prowess, evaluating your gains from a position of general ignorance as to what you're really buying/using. Being an end-user is being stuck at some minimum, having milked the curve you're at, until someone else comes disrupts your world for you. You make no real gains on your own, develop no only superficial mastery, mastering of the pane-of-glass atop the environment you dwell in.
It's really really hard to make a stronger better pitch for the school of lifelong learning & struggle. Often IDEs are a great way to understand what is possible, what tools to expect, but once you have a baseline, getting back into the command line, the terminal, the console & re-learning the hard way how to re-enact many of the things your IDE does for you is really hard. The learning curve is super slow, it takes ages to get out of the bottom reaches & start to feel ok. But you're gaining mastery not just of the programming job, but of the operating system, of the shell, of the real genuine honest environment of computing. Your ability to understand & see what is happening is so much higher, has such a more real connection than the pane-of-glass interface. Your ability to evaluate & direct yourself grows & amplifies over time, only if you invest in yourself & think of yourself as someone seeking a truthful engagement.
In general, I feel like the world has a lot of "what is the use case"/"what is the business value" thinking, and there's kind of an aggressive anti-exploratory value system that hates geekiness, that hates learning, that despises the enrichment of humankind, that rejects possibility. To insist on fast immediate obvious worth is to miss the big picture, is toxic to healthy ecosystems & diversity's neandering, exploring many many many tentacles. I want to see a world culture that believes in honest, genuine interactions, not fancy indecypherable veneers of things. Papert's Constructivism/Constructionism is a spiritual boon, one essential to what humanity became, and we should cherish, protect, & grow this light. https://en.wikipedia.org/wiki/Constructionism_(learning_theo...
> getting back into the command line, the terminal, the console & re-learning the hard way how to re-enact many of the things your IDE does for you is really hard.
So, if the IDE gives us those tools, what is the exact benefit of "going back and learning the hard way"?
> To insist on fast immediate obvious worth is to miss the big picture, is toxic to healthy ecosystems & diversity's neandering
How much time do I have to spend in the good old hard learning command line to replicate, say, 5% of Intellij Idea's refactoring capabilities and code navigation?
> So, if the IDE gives us those tools, what is the exact benefit of "going back and learning the hard way"?
Becoming a person of unlimited potential. Being capable of understanding & tackling anything, understanding the world you live in, not living like a marrionette shadow puppet your life.
> How much time do I have to spend in the good old hard learning command line to replicate, say, 5% of Intellij Idea's refactoring capabilities and code navigation?
Two afternoons learning CodeMod would provide a lifetime of infinite capabilities, versus some very limited preset scripts. You would be vastly vastly vastly greater, for a tiny amount of dickering around on your own.
"Becoming a person of unlimited potential." that's a very prosaic way of essentially saying nothing.
It all depends on what you want out of the system that you're using, for me personally the programming language, the IDE, the library that I incorporate, are all a means to an end, the goal to bring a unique idea into reality. I value the creation of new ideas more than the implementation itself and thus your suggestion is unsuitable for those of my kind.
I want to improve & grow, get better at computing.
This idea of being good enough, embracing mediocre capabilities for life & only focusing on shirt term output forever is exactly the local minima this post is warning against. Selling yourself a compromised future, being a passive consumer of technology, is anathema to the greater objectives of life & computing, in my view.
Selling yourself on comprimise, swearing you have served yourself, also seems hollow when one is deliberately snubbing trying to raise themselves to a perch where they are capable of evaluating. The anti-elite pitch is easy because it doesnt even have to get good enough to assess the merits & values of the school of lifelong learning & struggles. As for your precious output, it might be totally different & better if you had opted to invest in yourself & see technology as less than a lever you know how to crank.
We build on the shoulders of giants and there's nothing wrong with that. The terminal is just one abstraction down of an abstraction of an abstraction of an abstraction of an abstraction of an abstraction. Not very impressive.
Linux disagrees with you. A process is a core thing to the OS, not just "another abstraction". The terminal is an extremely shallow/direct interface to the OS, in a way distinctly more clear & certain than most other abstractions.
There's no better way to see real truth in computing. The shell exposes the base truths of the OS abstraction directly: processes, environment variables, stdio, signals, pipes. This is the fundamental toolkit of computing, and what higher-level abstractions we see (from language's stdlibs, to things like Kafka or SQS queues) are better understood in terms of the base computing fundamentals. The base unix tools define a clear set of capabilities we should be familiar with, & to call them just another abstraction, to focus on our own local platforms, ignores the base root that all computing so far eminates from.
This abstraction-relativism you present is highly dangerous. Arguing we shouldn't care about anything because there are abstractions everywhere ignores a realer truth, that some abstractions have been around & underpin nearly all systems & likely will continue to do so. We're only barely starting to play around with alternative conceptions, in projects like Fuschia. But this is a rare, novel, & just-emerging break from our common frameworks of computing. One that would behoove people to gain some competency in.
I agree, but one has to know the fundamentals to begin to evaluate their tools.
It's easy to just assume your tool works for you & it's the right pick, but precious few developers a) actually know computing well enough to assess the field of options, b) have any idea what they're buying.
It's heavyhanded bias that you've disregarded other options, and called whatever you think of as "best" and left everything else as "works ok all the time."
I see the small suite of built-ins as the "works ok", and not even "all of the time," just, for a couple small specific use cases. Learning about metaprogramming, ASTs, code-rewriting is a lifelong opportunity to get better, to understand what we really do when we write code at whole new levels, and those tools we truly, that truly fit the problems we actually have are the best tools.
That's pure demagoguery. As is, really, the rest of your response.
> Two afternoons learning CodeMod would provide a lifetime of infinite capabilities
That's not the answer to the question. So, you've learned CodeMod scripts . How much timeyou will then have to spend to replicate 5% of IntelliJ's refactoring capabilities? And while you're struggling to replicate that, how many capabilities you're missing out on?
> So, you've learned CodeMod scripts . How much timeyou will then have to spend to replicate 5% of IntelliJ's refactoring capabilities?
I was assuming you'd get >50% of the IntelliJ's refactoring you might potentially use in those two afternoons.
And you can invent new ones whenever you feel like in a couple hours.
Your attitude is balls dude, personal & not informational. Chill out, step off, desist from being personally insulting in your rplies. You have no idea how easy it is to replace this precious valued thing you so adore. That's not a problem. But you're getting wrapped up about it & becoming uncivil. You simply don't know. Stop getting worse.
I have studied computers from the ground up. At one point I could draw out most of the structure of a MIPS CPU. I have worked in Linux for years and think I know the shell very well. But none of that helps me deliver value to my employer. If an IDE or other high level tool can get the low level out of my way and get me more productive I'm much happier for it.
The benefit of an IDE is integrating compiler/editor/debugger/test runner/linter/profiler/source control/etc
If these things somehow prevent you from writing code that is as good as it would be without these integrations then what on earth were you doing? Apart from the “copilot” like things (which almost no one uses and which is orthogonal to the concept of IDEs, any editor can have that) what is “IDE-driven development”? Taking the first autocomplete suggestion after typing a dot in Java? instead of what? Reading docs? It’s not like the IDE having autocompletion for valid method names is forcing your hand to blindly take the first one or the wrong one? This reads a bit like that rant against syntax highlighting making developers bad.
This is an argument against programming by autocomplete, not an argument against programming with IDEs. IDEs make this method of programming possible, but they don't make it mandatory. The primary thing I use autocomplete for is to insert method calls that I already know that I want. Secondarily I use it like a documentation browser to read the documentation for every function that I could call if I'm trying to figure out a better way to do something. If you program by just selecting functions at random without taking the time to figure out the problem you're solving and the easiest way to solve it with the tools at your disposal, eschewing the IDE will not save you.
I do plenty of programming without autocomplete as well and it doesn't bother me. But it's certainly nice to have, it reduces a lot of the friction of finding documentation and putting code on the page when you already know what you want.
autocomplete is a memory multiplier.... it allows developers to be able to use vast/larger array of languages without having to remember every detail of the syntax.
As long as you know the concepts, autocomplete helps fills the details. This is especially useful if you are switching between multiple languages, from Java to Swift to Objective-C in one project. Autocomplete helps you keep productive and makes context switching much easier.
> This is an argument against programming by autocomplete, not an argument against programming with IDEs.
Exactly. IDEs fulfil an important function of removing repetitive and mundane tasks. The goal is to be you, the programmer, to know what you want to do and the tool, IDE, to make it happen as efficiently as possible.
That can happen through parsing code, showing documentation, showing references, alerting to obvious bugs, etc. But it can also be fulfilled by generating code (esp. in environments that like boilerplate) and possibly also by finding pieces of code to achieve the operation you need.
Sure, by using autocomplete constantly I may impair my memory same way that using Google Maps impairs my ability to drive without navigation. So what? I care that the task is completed and my mind is available to thinking about higher level problems rather than how to exactly search the code for references or locate the documentation.
Isn't the goal of software development actually building something rather than obsessing about the process?
There is an arrgument that the details matter a lot in code.
i mostly am familiar with network side of things, but little stuff like how you handle connection timeouts or retries, for example, make a really big difference to the overall quality of the system. Not thinking about a network call each time is setting up a system that will randomly fail in avoidable ways (excessive retries keeping a system from recoverying; excessive buffering in the face of
latency; unbounded memory queues causing failure propagatin; having best effort code handle connect failure quickly but not have good rear time outs, etc)
The higher level problems often emerge from the exact nature of the lower levels.
Agreed. I don’t think programming with autocomplete is even a problem so much as learning to program with autocomplete is a problem. I think everyone should start out with a barebones text editor to get used to thinking things through and not relying on advanced IDE features as crutches.
I mostly agree. It's a little hard for me to remember how I started because I'm almost fully self-taught and I never restricted myself like that. I think it's best to start people off with a friendly and helpful but minimal environment. Scratch is good for younger kids and is what I started with, and DrRacket is close to ideal for anyone older than maybe 10.
I use Ocaml and the type system and language server basically remove the need for things like a debugger, or even run-time testing while developing, that you might need in some other language. It tells you type of every function, variable, etc. While it's not needed, the language server works in tandem with the type system to basically tell you exactly what's happening in your code.
Type systems are half of the equation, but what do you do when the algorithm is wrong? Type systems don't constrain you from writing incorrect solutions to the echo cancelation problem...you need real world data and runtime tooling for that. This is where IDE type tooling shines, nobody cares about the editor or the code in the end...
Yeah. Autocomplete is about the least useful function of an IDE. The real killer features IMHO are the automatic refactoring tools (method renaming, addition of function arguments, etc) and, in languages that support it, the continuous build that points out errors and warnings as you type them. Code navigation features (go to definition, find every place where this function is called, open file by class name...) are also huge time savers. Autocomplete has its uses but ultimately it's not such a big deal. 99% of the time I use it, I already know what I want to write, and I just use it when I don't remember exactly the order of some function arguments or something like that.
EDIT: I'd like to add that the real speed comes when you have lots of keyboard commands ingrained in your muscle memory. There is a learning curve and it takes some time, but when you're comfortable with mapping certain very high level operations to a combination of 2 or 3 keys, the increase in speed is tremendous. The downside is that changing IDEs becomes a bit painful, so you built some kind of dependence. But this is not what the article is about.
I have ADHD and have terrible memory for names.
I'm not even using autocomplete that much, but the navigation in IDE really helps.... or hinders me from learning class/method names.
I have a very wiered and convoluted style of search and navigation, all to avoid remembering names, people who see me coding are really stunded by the way I navigate code.
The upside is I do really well with new languages/projects, unless we are talking millions of lines of code and hundreds of modules, then I begin to struggle again.
I'm currently mentoring someone from scratch and they're using autocompletion a lot. Have mixed feelings about it to be honest. I'm not a big fan of tools like Copilot and it'll be really hard for someone to convince me of its value.
On one side, it's as you mentioned. If you randomly pick a "solution" and hope that it works, you won't understand why you use that specific solution. And sure enough, many times they'd use autocomplete and get a solution that doesn't really solve the problem.
One particular problem I remember was a type difference issue. They had a string and needed to compare it with a string in an object. Easy, just do something like myObj.myVar == "string" right? But autocomplete suggested myObj.equals("string") instead. This is java code. Then I had to explain why it didn't work as intended even though the code compiled.
But observing it more, I decided not to stop them from doing it for now. I think it can be useful for learning purposes especially at the start. It's not that great for understanding but it does help them familiarize with all the different syntax and possibilities.
At the end of the day, I don't think it's that much different from randomly copying solutions from stack overflow until one works.
> One particular problem I remember was a type difference issue. They had a string and needed to compare it with a string in an object. Easy, just do something like myObj.myVar == "string" right? But autocomplete suggested myObj.equals("string") instead. This is java code. Then I had to explain why it didn't work as intended even though the code compiled.
Actually, you need to use `.equals()` for value equality on reference types in Java (like Strings). Using `==` will give you reference equality, which is almost never what you want. You probably wanted `myObj.myVar.equals("string")`
There's a common argument from craftsmen embedded in here. When something decreases accessibility of something difficult, the people who already know how to do the difficult thing criticize it, because from their eyes, it brings the average quality down. But ease and accessibility always win.
This goes for IDEs, programming languages, frameworks, etc. Think of a language like PHP, which made it so easy to code that countless shitty websites were made, ridden with spaghetti code and security issues. But, I was amongst probably tens of thousands of script kiddies who cut our teeth on PHP and eventually learned how to "properly" build web products. My first startup's MVP was a giant functions.php file and a bunch of templates, FTP'd onto a VPS. Probably wouldn't have gotten into it if instead I had needed to learn something like C++ or Java.
Yes, making something easier to do decreases the quality on average. But even skilled professionals can benefit from better accessibility. And it's hard to quantify the full benefit to those who wouldn't have been able to do the work without the lower barrier.
Personally, yes, I know if I blindly use Github Copilot I'll prob write some shitty code. But it just makes everything easier/faster to do. So I use it and put in a tiny bit of extra effort to make sure I'm not abusing it. And it's game-changing. I'm also sure tools like Copilot will improve at a pace that is much faster than people expect. It will recognize deprecated calls, misused calls, errors, security holes, etc.
A more eloquent way of putting this: lowering a barrier to do X will result in lower average quality of X, but more of it. Usually this is good, and lower barriers win. Unless it's like lowering the barrier to becoming a surgeon or something where the risk is high.
Rust's Send/Sync made multithreading easier, teaches people to write proper multithreaded code, and results in more reliable programs with less data races and race conditions. Rust's dependency managers makes dependencies easier, teaches people to add dependencies and transitive dependencies, and results in programmers not understanding their own programs.
I think that building tools to teach better programming (eg. teaching memory-safe programming or safe languages, teaching patterns immune to SQL injection or parsing exploits) is a great thing. But given the choice between bad and no code, I feel that it's almost better for people to not complete projects, than to release code with serious functional errors (memory leaks and segfaults and dozens of runtime race conditions that each show up every month or so, requiring herculean effort to debug, or more often go unsolved and haunt users indefinitely) or security defects (eg. https://lukeplant.me.uk/blog/posts/wordpress-4.7.2-post-mort...).
It's obviously better to teach good coding than to discourage people doing bad coding, but it's a lot harder (Send/Sync was a non-obvious innovation, and Rust required immense effort to push to 1.0 and build an ecosystem) and I don't think I can do it. And I'm opposed to the principle of trading off your understanding of a program to get more functionality from leaky abstractions (complex languages, optimizing compilers, big library trees, and GPU drivers all leak, whereas out-of-order CPUs and cache hierarchies are a mostly non-leaky abstraction).
One thing I've learned over 10 years of doing this is how much code is actually required to do anything, having more expressive language is one thing but tools that can help me cram out this stuff are also appreciated.
One thing I've learned over more than 10 years of doing this is how much code actually should be deleted instead of fixed. Thanks for giving me a reliable source of income ;)
I can't speak for Github CoPilot as I don't use it nor intend to ever use it but I find this article extremely unconvincing. He is basically considering an IDE as an autocomplete suggestion automaton. For me the features of an IDE that I use and value (fast code browsing both across my code and the code of my dependencies, refactoring support and taking care of mundane stuff like code formatting and import statements) have very little to do with autocomplete method suggestions.
I also find the workflow that author is describing where people blindly probe around until autocomplete suggests them a method that does what they want extremely unrealistic. Most developers will look up various libraries and options to accomplish a thing, indeed the only way you can get autocomplete to even work is if you kinda know what library/tooling you want to use.
For example if you want to use a b-tree for something the IDE can't read your mind, you're gonna have to go on the internet and see the options available in the language of your choice, weight them out, decide on one, add the library to dependency management file in your language and only then will the IDE be able to provide any help.
I've been using IDEs since Turbo Pascal came out. Delphi 5 was the most productive thing I've ever used for building GUI programs.
Python and languages that support lists, dictionaries, etc. natively have an advantage as far as expressivity. Generics and other support in Lazarus, the Delphi clone I use, lag far behind. However, for building GUI programs, it's still the best option for me.
Something even better for non-gui programs is IDLE, the python REPL... it lets you experiment with the data interactively, the make a program out of it, once you've figured out your algorithm, etc.
Better support of REPLs inside the IDE would be the way to go, I think.
I learned programming before IDEs existed so I think I can join the author's crotchety old elitist club. As such I'm also a sceptic of anything AI-driven or crowdsourced.
On the other hand, I recently allowed Visual Studio to use whatever their version of AI autocomplete is called and holy smokes - it can read my mind!
Sure, you can complain about how things were better before the latest crop of tools allowed the unwashed masses to trample your domain but if you're smart you take advantage of the good parts while being aware of the bad ones.
I've always thought Lars Andersen's archery did a pretty good job making this point. https://youtu.be/BEG-ly9tQGk What will the crossbow wielding programmers of the future look like and who will be selling the crossbows?
On the theory level the article talks about I don’t really have a problem with IDEs Not always suggesting the sort of optimal solution so long as it reduces my cognitive load and gets the job done.
Regarding copilot, I’d say it guesses the exact code I would write or code that is very similar to it over 50% of the time. My main complaint there is sometimes it oddly miss places a parentheses and sometimes it seems to block the code completion function of VS code. This is with typescript/jsx. Other than that which I assume is going to be fixed eventually copilots been a very pleasant experience for me.
>We end up knowing less than we should and get less than we deserve.
Speak for yourself.
When I program it's to get things done, I need to read a text file. Auto complete me a solution.
C# would be impossible without an IDE. Maybe you can write something in JavaScript, but any language with a large standard library is impossible sans IDE
Time you spend fiddling with tools trying to replicate a tiny portion of what an IDE offers can be spent actually doing mental exercises to keep your brain healthy.
I would absolutely fire someone who refused to use the mechanized tree harvester I provided and insisted on felling trees with an axe, and that's about where I stand with respect to insisting on using PDP-10 era text editors over an IDE.
Having spent a few years in Perl I understand some of the frustration of an IDE. I find dynamic languages don't gain a lot from an IDE. But if you're in something with stronger types like Java, typescript or F# the IDE is a God send. The best tool ever is refactor rename. When the IDE can parse your entire code base and rename just the function or variable you want it's amazing. Go to definition is worlds better too.
I found, in Perl and JavaScript, these tools didn't work reliably enough so the IDE was just a slower tool.
Also reading the documentation is important regardless of the tool you're using. I don't think that's a true reflection of IDE development.
Haha I've not heard that one. Perl is very much an unreadable code soup.
I will have to try on next time I'm in plain JS. It doesn't happen often. I have a preference for strongly typed languages. I suspect I have something similar to dyslexia. I mix the spelling of words and sometimes even the words. Strong typing is the tool that makes that problem go away.
I use Intellij and it really does its level best to bring code insight to dynamic languages.
But I fully agree wrt types. Even if I'm not using an IDE, types, or type hints a la Python, help me understand what's going on far better.
I once heavily refactored a hand-rolled build tool written entirely in Python that read and write JSON. Everyone was terrified of touching it.
Introducing Pydantic to replace dicts of dicts of dicts with dicts of App instances that had Environments immediately made the code far easier to understand.
Then introducing type annotations and mypy completed the transition of a business critical tool from one everyone previously approached in what I called a "special forces" manner (get in, achieve your very narrow goal, get out before anyone notices you) to something where code flow was easily understandable.
Immediately, the tool received a lot of attention and refactoring. Something like 20% of it was dead code, amd there was some functionality that, had it been used, would've corrupted the build state or just flat out died.
And it was simply adding types that made this obvious, and made the code accessible to people who wanted to refactor it fearlessly.
(Unit tests were entirely absent, but without the understanding of the code that types brought, how would you even start?)
Refactor functionalities in JetBrains tools probably saved tons of hours of incidents, typo bugs, copy and paste... only that makes IDE Driven Development as completely worthed it.
Also, tools such as Tabnine take away the plumbing from coding - I am so much more focused on the high-level design and goal of what I am doing if I don't have to pass so much time trying to remember what I wanted to write...
Some schools out there encourage students to do as much as they can with the terminal (at least, for the first semester) and a simple text editor.
The side effect is that there’s no IDE magic behind builds (it’s all plain makefiles and command line tools the students can run on their own). There’s no smart completion, so you have to go out and browse man pages or official documentation.
This seems to be about autocomplete /github co-pilot rather than IDE's which is more of a plugin which I'm sure nearly every editor will get. I actually really like copilot, I've been using it for a while and it often ends up generating a lot of the code I need. It's not perfect, but definitely speeds things up a lot.
> Since he didn’t have suggestions to guide him, he read the docs and by simply perusing them, was aware of methods and other features that the IDE did not suggest.
So Mel, not only did not use IDEs, he did not use compilers, or even an assembler because they got in his way of deep knowledge of the instruction set of the computer as well as the performance characteristics of the hardware he was programming.
Because of that, he was able to achieve program efficiency in both space and time that others could only dream of.
The "real programmers" don't do X, trope has been going of since before most of the people of this forum were even born.
And Mel is a great story, but it is also misses that engineering is about tradeoffs. And in many, many programs, space and time efficiency is actually way, way less important than maintainability, extensibility, etc. There will always be the cases where deep knowledge of the fundamentals of computers and computer science will make or break a program. But for a large part of most programs, premature optimization is still the root of all evil.
There's a lot here I resonate with. Ironically, I'm sort of headed in the opposite direction—I've been spending more effort experimenting with and working with tooling in VSCode to add autocomplete/docs/type hints/etc. for Ruby projects. My background is essentially IDE-free…for years I programmed Ruby and JavaScript using nothing but BBCode!
I definitely think there's a sweet spot somewhere in the middle here, and industry trends are likely headed too far into IDE-plus-AI-all-the-things! territory. Over time, I think we'll come to understand the tradeoffs better.
I feel like this is more of a commentary on dynamic vs statically typed languages under the guise of being about (a poor caricature of) IDEs. Autocomplete for dynamic typed languages has always been a really hard problem, but that’s less than 10% of what an IDE does for you.
When the main reason for you to use an IDE is to write code, you are missing out the most important part. An IDE helps you to reason about code, to navigate it, to read it, easily.
> He’s a really good programmer, but that’s not why his solutions were better.
I disagree, if he was forced to use IDE he would came up with the exact same solutions. People who disregard IDEs generally are good, and thy disregard helpful tools like IDE at least partially due to their arrogance. Also their supposed "simple editors" with various extensions are often very close to IDEs in term of functionality.
Author also seem to used perl for demonstration, which makes me not so certain he benefits from IDE all that much. The key benefits of IDE truly starts to open when you start using typed language. This shows especially clearly when you use python (in PyCharm for example) and start adding type annotation. Is a completly different experience.
You start getting:
- reliable autocomplete (as mentioned)
- reliable refactoring (this is big, because one of the major cry about python is that as it grows it gets hard to maintain)
- showing errors immediately without having to run the code
No matter how good you are all these things make you better.
Note: Above argument doesn't apply to github-copilot (which was used as a demo), it's probably no surprise that using that tool will get someone to arrive with same source code. Especially if it is a tutorial so many people before you typed similar thing as well.
142 comments
[ 3.2 ms ] story [ 197 ms ] threadAll in all, I don't see the link between using an IDE or not and the quality of the outcome. But I do see the link between using an IDE and development speed, where refactoring is just so much faster and less error prone if you have a decent IDE.
I haven't tried copilot yet, so can't say much about it.
8x--------------
He’s a really good programmer, but that’s not why his solutions were better. Since he didn’t have suggestions to guide him, he read the docs and by simply perusing them, was aware of methods and other features that the IDE did not suggest. There were better ways in the libraries they were using that weren’t apparent in the IDE. And that makes sense: in the interface for a suggestion in an editor, how much complexity can you really manage?
8x--------------
it makes sense to me - if the API is large and complex enough that you can discover good ways to do things via serendipity, IDE autosuggestions will stick you in a local maximum.
8<———————
Looks nicer.
Never seen it before. Good idea. Gonna use it from now on instead of quotes or > on every line!
> "He’s a really good programmer, but that’s not why his solutions were better. Since he didn’t have suggestions to guide him, he read the docs and by simply perusing them, was aware of methods and other features that the IDE did not suggest. There were better ways in the libraries they were using that weren’t apparent in the IDE. And that makes sense: in the interface for a suggestion in an editor, how much complexity can you really manage?"
The company had just released a new SDK to access a data repository. Since it was a brand new library, they only had Java/Scala versions, with plans to support other languages (JS, Python being the next two on their roadmap) in the few quarters. My team, primarily researchers who only knew Python, needed to use some of this data for a new project. I figured, what the hell, I've been looking for an excuse to learn some Scala, I'll see if I can throw together a utility for my team to use to get access to this data sooner. I fired up Sublime Text and opened up the docs for the SDK and got to work. The documentation was terrible and I really struggled to do basic tasks with this SDK. Simple things like what types were expected for function parameters was just non-existent. Since this SDK was planned to be released publicly to customers, I thought I'd do my co-workers a favour and sent them a message with some feedback about places where I particularly struggled with understanding how to use their SDK, thinking I could help improve the documentation before this went out to paying customers. Their response was that if I just used a proper IDE for my development, I wouldn't have these problems since the code completion/suggestions would let me know what the types of parameters were.
That experience completely soured me on the JVM ecosystem and I walked away from learning it. When I finally came back two years later, I discovered that I actually really like working in Scala (admittedly I do use Intellij for it now), but that many library's documentation is still quite poor compared to what I've come to expect for Python libraries.
But why is documenting the types helpful? The IDE, and for Java/JVM there's a choice of multiple, will tell you. Why waste precious hours of life rewriting what is already documented in the type system?
Sure I'd document the why of something but the idea types should have any form of documentation external to an IDE that can parse the language just seems... redundant.
Whenever I hop over the fence to dynamic languages sure I have to read documentation and large amounts of it is rubbish that could just be inferred from source but that's why I don't hop over there often.
All in all, I don't see the link between using an IDE or not and the quality of the outcome.
That seems to be a pretty good link to me already...
I worked (briefly, fortunately) with Java for a short while a long time ago. The fact that even "small" Java projects are often ridiculously overengineered and so complex that an IDE is almost obligatory to work with the code in any meaningful way should itself be a sign of what dependence on IDEs tends to cause. The article mentions that too, and my experience agrees.
But the author was basically saying that you can write better Java in an editor than if you were using an IDE. And this doesn't make sense to me. The code a skilled programmer will write with or without an IDE won't be that different.
Isn't that because dealing with the complexity of many modern Java frameworks and surrounding tooling is pretty much impossible without an IDE?
I remember the 90s IDEs. They were not fun. But still better than nothing!
Thanks to Copilot, etc bad programmers can now get a lot further, and perhaps it would be good for them to struggle so that they can become better, but don't lay bad code at the feet of an IDE.
In the 90s IDEs were all the rage, from Turbo Pascal to Visual Basic - the pinnacle of usability IMO.
> This happens in just about anything you can imagine, but let’s consider IDEs. You start using an IDE and it makes one particular thing particularly easy, and it makes it so easy that you don’t go looking for something even easier. You can’t spend all of your time wondering if there’s a slightly better way of doing things.
This argument resonates fairly well with me. I generally view IDEs as low commitment, a rapid learning curve to completion, with very hard caps on what you are going to find. You'll understand what the tool gives you, and then you'll be done. There's some trading/collecting hooks to keep you feeling like you can improve, to collect all the best plugins to improve the base system, but you're still a consumer, hunting for solutions, and you never really gain intimacy, understanding, or general prowess, evaluating your gains from a position of general ignorance as to what you're really buying/using. Being an end-user is being stuck at some minimum, having milked the curve you're at, until someone else comes disrupts your world for you. You make no real gains on your own, develop no only superficial mastery, mastering of the pane-of-glass atop the environment you dwell in.
It's really really hard to make a stronger better pitch for the school of lifelong learning & struggle. Often IDEs are a great way to understand what is possible, what tools to expect, but once you have a baseline, getting back into the command line, the terminal, the console & re-learning the hard way how to re-enact many of the things your IDE does for you is really hard. The learning curve is super slow, it takes ages to get out of the bottom reaches & start to feel ok. But you're gaining mastery not just of the programming job, but of the operating system, of the shell, of the real genuine honest environment of computing. Your ability to understand & see what is happening is so much higher, has such a more real connection than the pane-of-glass interface. Your ability to evaluate & direct yourself grows & amplifies over time, only if you invest in yourself & think of yourself as someone seeking a truthful engagement.
In general, I feel like the world has a lot of "what is the use case"/"what is the business value" thinking, and there's kind of an aggressive anti-exploratory value system that hates geekiness, that hates learning, that despises the enrichment of humankind, that rejects possibility. To insist on fast immediate obvious worth is to miss the big picture, is toxic to healthy ecosystems & diversity's neandering, exploring many many many tentacles. I want to see a world culture that believes in honest, genuine interactions, not fancy indecypherable veneers of things. Papert's Constructivism/Constructionism is a spiritual boon, one essential to what humanity became, and we should cherish, protect, & grow this light. https://en.wikipedia.org/wiki/Constructionism_(learning_theo...
So, if the IDE gives us those tools, what is the exact benefit of "going back and learning the hard way"?
> To insist on fast immediate obvious worth is to miss the big picture, is toxic to healthy ecosystems & diversity's neandering
How much time do I have to spend in the good old hard learning command line to replicate, say, 5% of Intellij Idea's refactoring capabilities and code navigation?
Becoming a person of unlimited potential. Being capable of understanding & tackling anything, understanding the world you live in, not living like a marrionette shadow puppet your life.
> How much time do I have to spend in the good old hard learning command line to replicate, say, 5% of Intellij Idea's refactoring capabilities and code navigation?
Two afternoons learning CodeMod would provide a lifetime of infinite capabilities, versus some very limited preset scripts. You would be vastly vastly vastly greater, for a tiny amount of dickering around on your own.
It all depends on what you want out of the system that you're using, for me personally the programming language, the IDE, the library that I incorporate, are all a means to an end, the goal to bring a unique idea into reality. I value the creation of new ideas more than the implementation itself and thus your suggestion is unsuitable for those of my kind.
This idea of being good enough, embracing mediocre capabilities for life & only focusing on shirt term output forever is exactly the local minima this post is warning against. Selling yourself a compromised future, being a passive consumer of technology, is anathema to the greater objectives of life & computing, in my view.
Selling yourself on comprimise, swearing you have served yourself, also seems hollow when one is deliberately snubbing trying to raise themselves to a perch where they are capable of evaluating. The anti-elite pitch is easy because it doesnt even have to get good enough to assess the merits & values of the school of lifelong learning & struggles. As for your precious output, it might be totally different & better if you had opted to invest in yourself & see technology as less than a lever you know how to crank.
There's no better way to see real truth in computing. The shell exposes the base truths of the OS abstraction directly: processes, environment variables, stdio, signals, pipes. This is the fundamental toolkit of computing, and what higher-level abstractions we see (from language's stdlibs, to things like Kafka or SQS queues) are better understood in terms of the base computing fundamentals. The base unix tools define a clear set of capabilities we should be familiar with, & to call them just another abstraction, to focus on our own local platforms, ignores the base root that all computing so far eminates from.
This abstraction-relativism you present is highly dangerous. Arguing we shouldn't care about anything because there are abstractions everywhere ignores a realer truth, that some abstractions have been around & underpin nearly all systems & likely will continue to do so. We're only barely starting to play around with alternative conceptions, in projects like Fuschia. But this is a rare, novel, & just-emerging break from our common frameworks of computing. One that would behoove people to gain some competency in.
It's easy to just assume your tool works for you & it's the right pick, but precious few developers a) actually know computing well enough to assess the field of options, b) have any idea what they're buying.
It's heavyhanded bias that you've disregarded other options, and called whatever you think of as "best" and left everything else as "works ok all the time."
I see the small suite of built-ins as the "works ok", and not even "all of the time," just, for a couple small specific use cases. Learning about metaprogramming, ASTs, code-rewriting is a lifelong opportunity to get better, to understand what we really do when we write code at whole new levels, and those tools we truly, that truly fit the problems we actually have are the best tools.
That's pure demagoguery. As is, really, the rest of your response.
> Two afternoons learning CodeMod would provide a lifetime of infinite capabilities
That's not the answer to the question. So, you've learned CodeMod scripts . How much timeyou will then have to spend to replicate 5% of IntelliJ's refactoring capabilities? And while you're struggling to replicate that, how many capabilities you're missing out on?
> So, you've learned CodeMod scripts . How much timeyou will then have to spend to replicate 5% of IntelliJ's refactoring capabilities?
I was assuming you'd get >50% of the IntelliJ's refactoring you might potentially use in those two afternoons.
And you can invent new ones whenever you feel like in a couple hours.
Your attitude is balls dude, personal & not informational. Chill out, step off, desist from being personally insulting in your rplies. You have no idea how easy it is to replace this precious valued thing you so adore. That's not a problem. But you're getting wrapped up about it & becoming uncivil. You simply don't know. Stop getting worse.
If these things somehow prevent you from writing code that is as good as it would be without these integrations then what on earth were you doing? Apart from the “copilot” like things (which almost no one uses and which is orthogonal to the concept of IDEs, any editor can have that) what is “IDE-driven development”? Taking the first autocomplete suggestion after typing a dot in Java? instead of what? Reading docs? It’s not like the IDE having autocompletion for valid method names is forcing your hand to blindly take the first one or the wrong one? This reads a bit like that rant against syntax highlighting making developers bad.
I do plenty of programming without autocomplete as well and it doesn't bother me. But it's certainly nice to have, it reduces a lot of the friction of finding documentation and putting code on the page when you already know what you want.
As long as you know the concepts, autocomplete helps fills the details. This is especially useful if you are switching between multiple languages, from Java to Swift to Objective-C in one project. Autocomplete helps you keep productive and makes context switching much easier.
Exactly. IDEs fulfil an important function of removing repetitive and mundane tasks. The goal is to be you, the programmer, to know what you want to do and the tool, IDE, to make it happen as efficiently as possible.
That can happen through parsing code, showing documentation, showing references, alerting to obvious bugs, etc. But it can also be fulfilled by generating code (esp. in environments that like boilerplate) and possibly also by finding pieces of code to achieve the operation you need.
Sure, by using autocomplete constantly I may impair my memory same way that using Google Maps impairs my ability to drive without navigation. So what? I care that the task is completed and my mind is available to thinking about higher level problems rather than how to exactly search the code for references or locate the documentation.
Isn't the goal of software development actually building something rather than obsessing about the process?
i mostly am familiar with network side of things, but little stuff like how you handle connection timeouts or retries, for example, make a really big difference to the overall quality of the system. Not thinking about a network call each time is setting up a system that will randomly fail in avoidable ways (excessive retries keeping a system from recoverying; excessive buffering in the face of latency; unbounded memory queues causing failure propagatin; having best effort code handle connect failure quickly but not have good rear time outs, etc)
The higher level problems often emerge from the exact nature of the lower levels.
The details of resulting code. Not the details of how exactly you wrote it.
EDIT: I'd like to add that the real speed comes when you have lots of keyboard commands ingrained in your muscle memory. There is a learning curve and it takes some time, but when you're comfortable with mapping certain very high level operations to a combination of 2 or 3 keys, the increase in speed is tremendous. The downside is that changing IDEs becomes a bit painful, so you built some kind of dependence. But this is not what the article is about.
I have a very wiered and convoluted style of search and navigation, all to avoid remembering names, people who see me coding are really stunded by the way I navigate code.
The upside is I do really well with new languages/projects, unless we are talking millions of lines of code and hundreds of modules, then I begin to struggle again.
On one side, it's as you mentioned. If you randomly pick a "solution" and hope that it works, you won't understand why you use that specific solution. And sure enough, many times they'd use autocomplete and get a solution that doesn't really solve the problem.
One particular problem I remember was a type difference issue. They had a string and needed to compare it with a string in an object. Easy, just do something like myObj.myVar == "string" right? But autocomplete suggested myObj.equals("string") instead. This is java code. Then I had to explain why it didn't work as intended even though the code compiled.
But observing it more, I decided not to stop them from doing it for now. I think it can be useful for learning purposes especially at the start. It's not that great for understanding but it does help them familiarize with all the different syntax and possibilities.
At the end of the day, I don't think it's that much different from randomly copying solutions from stack overflow until one works.
Actually, you need to use `.equals()` for value equality on reference types in Java (like Strings). Using `==` will give you reference equality, which is almost never what you want. You probably wanted `myObj.myVar.equals("string")`
This goes for IDEs, programming languages, frameworks, etc. Think of a language like PHP, which made it so easy to code that countless shitty websites were made, ridden with spaghetti code and security issues. But, I was amongst probably tens of thousands of script kiddies who cut our teeth on PHP and eventually learned how to "properly" build web products. My first startup's MVP was a giant functions.php file and a bunch of templates, FTP'd onto a VPS. Probably wouldn't have gotten into it if instead I had needed to learn something like C++ or Java.
Yes, making something easier to do decreases the quality on average. But even skilled professionals can benefit from better accessibility. And it's hard to quantify the full benefit to those who wouldn't have been able to do the work without the lower barrier.
Personally, yes, I know if I blindly use Github Copilot I'll prob write some shitty code. But it just makes everything easier/faster to do. So I use it and put in a tiny bit of extra effort to make sure I'm not abusing it. And it's game-changing. I'm also sure tools like Copilot will improve at a pace that is much faster than people expect. It will recognize deprecated calls, misused calls, errors, security holes, etc.
I think that building tools to teach better programming (eg. teaching memory-safe programming or safe languages, teaching patterns immune to SQL injection or parsing exploits) is a great thing. But given the choice between bad and no code, I feel that it's almost better for people to not complete projects, than to release code with serious functional errors (memory leaks and segfaults and dozens of runtime race conditions that each show up every month or so, requiring herculean effort to debug, or more often go unsolved and haunt users indefinitely) or security defects (eg. https://lukeplant.me.uk/blog/posts/wordpress-4.7.2-post-mort...).
It's obviously better to teach good coding than to discourage people doing bad coding, but it's a lot harder (Send/Sync was a non-obvious innovation, and Rust required immense effort to push to 1.0 and build an ecosystem) and I don't think I can do it. And I'm opposed to the principle of trading off your understanding of a program to get more functionality from leaky abstractions (complex languages, optimizing compilers, big library trees, and GPU drivers all leak, whereas out-of-order CPUs and cache hierarchies are a mostly non-leaky abstraction).
I also find the workflow that author is describing where people blindly probe around until autocomplete suggests them a method that does what they want extremely unrealistic. Most developers will look up various libraries and options to accomplish a thing, indeed the only way you can get autocomplete to even work is if you kinda know what library/tooling you want to use.
For example if you want to use a b-tree for something the IDE can't read your mind, you're gonna have to go on the internet and see the options available in the language of your choice, weight them out, decide on one, add the library to dependency management file in your language and only then will the IDE be able to provide any help.
Python and languages that support lists, dictionaries, etc. natively have an advantage as far as expressivity. Generics and other support in Lazarus, the Delphi clone I use, lag far behind. However, for building GUI programs, it's still the best option for me.
Something even better for non-gui programs is IDLE, the python REPL... it lets you experiment with the data interactively, the make a program out of it, once you've figured out your algorithm, etc.
Better support of REPLs inside the IDE would be the way to go, I think.
On the other hand, I recently allowed Visual Studio to use whatever their version of AI autocomplete is called and holy smokes - it can read my mind!
Sure, you can complain about how things were better before the latest crop of tools allowed the unwashed masses to trample your domain but if you're smart you take advantage of the good parts while being aware of the bad ones.
Regarding copilot, I’d say it guesses the exact code I would write or code that is very similar to it over 50% of the time. My main complaint there is sometimes it oddly miss places a parentheses and sometimes it seems to block the code completion function of VS code. This is with typescript/jsx. Other than that which I assume is going to be fixed eventually copilots been a very pleasant experience for me.
Speak for yourself.
When I program it's to get things done, I need to read a text file. Auto complete me a solution.
C# would be impossible without an IDE. Maybe you can write something in JavaScript, but any language with a large standard library is impossible sans IDE
In this case, mental exercise keeps the brain healthy.
I would absolutely fire someone who refused to use the mechanized tree harvester I provided and insisted on felling trees with an axe, and that's about where I stand with respect to insisting on using PDP-10 era text editors over an IDE.
I found, in Perl and JavaScript, these tools didn't work reliably enough so the IDE was just a slower tool.
Also reading the documentation is important regardless of the tool you're using. I don't think that's a true reflection of IDE development.
As for JS and IDEs, you should try an IDE again. Far better.
I will have to try on next time I'm in plain JS. It doesn't happen often. I have a preference for strongly typed languages. I suspect I have something similar to dyslexia. I mix the spelling of words and sometimes even the words. Strong typing is the tool that makes that problem go away.
It has been said that perl is the only language which looks the same both before and after RSA encryption.
But I fully agree wrt types. Even if I'm not using an IDE, types, or type hints a la Python, help me understand what's going on far better.
I once heavily refactored a hand-rolled build tool written entirely in Python that read and write JSON. Everyone was terrified of touching it.
Introducing Pydantic to replace dicts of dicts of dicts with dicts of App instances that had Environments immediately made the code far easier to understand.
Then introducing type annotations and mypy completed the transition of a business critical tool from one everyone previously approached in what I called a "special forces" manner (get in, achieve your very narrow goal, get out before anyone notices you) to something where code flow was easily understandable.
Immediately, the tool received a lot of attention and refactoring. Something like 20% of it was dead code, amd there was some functionality that, had it been used, would've corrupted the build state or just flat out died.
And it was simply adding types that made this obvious, and made the code accessible to people who wanted to refactor it fearlessly.
(Unit tests were entirely absent, but without the understanding of the code that types brought, how would you even start?)
Also, tools such as Tabnine take away the plumbing from coding - I am so much more focused on the high-level design and goal of what I am doing if I don't have to pass so much time trying to remember what I wanted to write...
The side effect is that there’s no IDE magic behind builds (it’s all plain makefiles and command line tools the students can run on their own). There’s no smart completion, so you have to go out and browse man pages or official documentation.
This post reminded me of the story of Mel.
http://catb.org/jargon/html/story-of-mel.html
So Mel, not only did not use IDEs, he did not use compilers, or even an assembler because they got in his way of deep knowledge of the instruction set of the computer as well as the performance characteristics of the hardware he was programming.
Because of that, he was able to achieve program efficiency in both space and time that others could only dream of.
The "real programmers" don't do X, trope has been going of since before most of the people of this forum were even born.
This is just another manifestation of this trope.
I definitely think there's a sweet spot somewhere in the middle here, and industry trends are likely headed too far into IDE-plus-AI-all-the-things! territory. Over time, I think we'll come to understand the tradeoffs better.
I disagree, if he was forced to use IDE he would came up with the exact same solutions. People who disregard IDEs generally are good, and thy disregard helpful tools like IDE at least partially due to their arrogance. Also their supposed "simple editors" with various extensions are often very close to IDEs in term of functionality.
Author also seem to used perl for demonstration, which makes me not so certain he benefits from IDE all that much. The key benefits of IDE truly starts to open when you start using typed language. This shows especially clearly when you use python (in PyCharm for example) and start adding type annotation. Is a completly different experience.
You start getting:
- reliable autocomplete (as mentioned)
- reliable refactoring (this is big, because one of the major cry about python is that as it grows it gets hard to maintain)
- showing errors immediately without having to run the code
No matter how good you are all these things make you better.
Note: Above argument doesn't apply to github-copilot (which was used as a demo), it's probably no surprise that using that tool will get someone to arrive with same source code. Especially if it is a tutorial so many people before you typed similar thing as well.