I really hate that we use so many analogies when teaching programming.
A programming language is not an instrument. Its a language that lies somewhere between logic, math, and actual spoken language.
When I was learning guitar, it wasn't filled with analogies like "A guitar is like a broom, you've got to learn to sweep across the strings consistently". They just said, learning guitar is hard, practice and you will get better.
Don't dumb it down for people learning, just say straight out. "Using an IDE will hide the low level things like compilation that you will need to know to be a good programmer".
Actually, I play guitar, and read sheet music, and this analogy is less about programming and more about an aspect of learning a subject. If you take the easy tool based route, then you're dependent on the tool you use. If you take the harder more universal less tool based route then you have more generally applicable skill.
Given the quality of most guitar education though, I wouldn't take their lack of using analogy as any kind of bonus. Guitarists are notorious for bullshit education that's basically, "No look at me do it. I can't explain how I do it. Just like this. No wrong!" If they were better at explaining and bridging concepts using existing concepts people have then they might be better at teaching it.
I actually think it depends on the analogy. For some reason, people love to compare programming to art and music. The article Dabblers and Blowhards[1] is a great response to these types of claims. A better analogy for programming is that it's like math. Once you understand how the operations work, you appreciate the value of a calculator.
Actually, that article is full of errors regarding painting, art history, and a lot of his criticisms of PG's take on art history are just plain wrong. Which is typical of painters. Many don't even know the chemical makeup of their pigments or which ones are dangerous and why. Many don't know about how projection was used to do a huge amount of art long before there were cameras.
The reason people use analogies for programming is it's not as common in the general population so we need something they can latch onto that they do no. Music and art are deeply embedded in everyone's knowledge, so they're easy analogies. Math isn't as deeply embedded so it's not as useful unless the person has a background in math.
Even then, I've taught people with solid math or engineering backgrounds that still struggled with programming concepts. Programming is just weird and hard to explain.
That still doesn't change the fact that art and music are poor analogies. I struggle with the best way to describe this, but at the end of the day, perhaps the best analogy I can give is that the purpose of art and music is to share the artist's thoughts and feelings with his audience. It's completely subjective. Programming, on the other hand, is more utilitarian. No one cares how beautiful the underlying code is, user care only if the damn thing works the way it's expected. Learning to code well is important for the inevitable maintenance, but at the end of the day, if the program doesn't work, few people will appreciate it.
Coding is more like music than math. Multiple parts work together cohesively to create something bigger. Just like music, a program or library always has a beginning, a middle, and an end.
Music and programming are creative tasks that require you to think of new ways to solve problems or express yourself. Math is a system of calculation.
Wow, I have rewritten my response more than once, but I am basically amazed at how completely wrong this response is. Coding is a system of calculation as well. Like math, the goal of programming is to solve a problem. There are beautiful, elegant, and creative solutions in both math and coding, but first you have solve the damn problem. Music is basically about self expression, it's a means unto itself, it has no problem to solve.
You're missing a step. The goal of programming is not to just solve a problem, it is to create a solution to a problem. That creating part is the most important part.
You're either being inane, dense, or you're just plain inexperienced. Coding, like math, has an element to creativity to it. If you don't think math has creativity, you don't know anything about more advanced math. However, despite how technically brilliant, how sublime your solution may be, if it doesn't actually SOLVE the problem you set out to solve, it's not very useful.
Protip: If 80% of your agument is an analogy, it's probably not a very good argument.
I think the opposite is true, IDEs help you find out what is really going on, by showing you (depending on the language) which module is used where and giving you the option to directly navigate to that source. That in turn confronts the beginner with the code and conventions of other (more experienced) coders. So yeah, IDEs rock. Also debugging...
IDE's aren't the only way to find out which module is used. Why is this such a mystery in the first place? Is it because the programmer doesn't know, because they don't care to know, or is it because the details for how to find out what modules are used in your project are hidden in some sort of arcane manner which precludes their extraction with simpler tools?
IDE's are great if you use them. Editors are, too. But the point is that an over-reliance on IDE's will degrade your skills, generally, and command/control over your project, precisely because it does too much work for you, and your understanding of the subject thus atrophies. If I had a Btc for every new-school "IDE's are the awesome, can't live without them" superstar programmer who nonetheless couldn't navigate his way around the build system, or even directory hierarchy for their very-valuable software system, I wouldn't have to write software for a living. Probably.
It is sage advice, this "don't become addicted to your IDE" statement, because IDE's are also a walled garden, folks. There are reasons the "Developers^3"-mindset was so ironic way back then; if, as a platform vendor, you capture developer mindsets then you safeguard your platform from being undermined by your competition: other developers. Never forget that its turtles, all the way down, folks .. and your average modern IDE is a big, hungry, fat one.
I'm not the biggest Zed fan out there because I find him to be overly defensive at times, but this is a small section of a larger work aimed at teaching people how to program in a certain language. I don't know about the rest of you, but when I learn a new language, I open a basic text editor and a command prompt and get to it, because it forces me to learn the style and convention of the language. Once I've got that down, I'll use whatever the hell makes me the most useful.
A confused illogical comment criticizing me charging for something I made (that's free BTW) from a guy on a website run by a company that makes money making companies that charge for things (usually).
Being an advocate of learning something without breaking it down into smaller pieces shows an ignorance of learning in general. Everyone has a limit to their mental capacity and the logical leaps they can figure out with incomplete information. IDEs reduce the mental energy needed at any one time. Every time someone makes something easier, there are always people who are advocates against it and they always are on the losing side of history. Yes, there are lots of kids using Unity and Javascript who don't understand memory, or compilers yet. But they can learn and learn that one chunk at a time instead of having to take on so much at once just to make any progress at all.
This is some of the worst bullshit I've read in quite some time.
USE AN IDE. It's there to take care of the boilerplate crap for you. It's there to correct your typos. It's there to give you instant lookup of API calls. It's there to flag your syntax errors so you don't have to do the annoying "code, compile, placate the compiler, repeat" cycle. Using an IDE will NOT make you stupid. People who advocate this view are the same kind of people who insist on a manual transmission as an indicator of a good driver. IT'S NOT.
Real bullshit is spewed when someone make comments about something they don't know anything about.
This advice given about not using IDEs is on a site teaching programming in C to complete beginners. If you had spend just a few minutes on the site, you would have realized that there is no boilerplate crap to learn in the lessons he teaches and that it makes a lot of sense at that level to forego using an IDE and focusing on learning the language using a simple editor, rather than spending a lot of time learning to use a specialized tool.
Or just use an IDE so you can focus on the language rather than his idea of the proper (command line) tooling. This would be ESPECIALLY helpful for complete beginners.
I've taught many people C, and it's always gone a LOT smoother with an IDE.
Thank you, I needed that. Since I got a new job recently, and switched from PHP to C# .NET, and therefore have to use VisualStudio, I feel totally dumbed down, as I have barely any idea what is happening most of the time.
And I started to blame myself for this. So this piece really speaks to me, and confirms me that it might not be my fault here.
It's odd that people read my comment and assume I'm binary about IDEs. I'm a pragmatist, and I say use the tool that works.
I tell people they shouldn't be dependent on IDEs to write software because that gives them choice and control over their career. That doesn't mean I'm saying people should neverever use and IDE. In your situation I would have studied everything that microsoft puts out and learn to own VisualStudio. If I have to use a tool, I learn to hack the hell out of it and own it so that I'm not screwed when I need to use it.
I suggest you bite the bullet and put in the time to get good at it. I would start here:
I think that's a Microsoft site. There's plenty of other courses online that will teach you, and they should be a tax write-off since that's professional development.
There is ample evidence that the rising market for IDE's is producing cruddier software, and I think your position is a fair one for anyone with any experience in the industry to hold, given that there is ample history of the subject to support the fact that the first-line of attack for any platform vendor is in the developer tools realm. No system worth its salt ever shipped without some form of development environment - and the slicker, and easier to use, the better. Anyone can pick up Visual Studio these days and bang a few things together to make their computer operate; whats sad is that its not just a built-in feature of the OS, though, and is instead guided as a product by marketing people whose desire really is to gain impressions, capture mindsets, and lock people into their brand. Your average editor doesn't do much of that; your average IDE does a hell of a lot of it. Yours is therefore a valid argument, in my opinion ..
No, it's your fault. Saying your IDE is to blame is the equivalent of saying using C to program is making you stupid because it abstracts you too far away from the underlyung architectures. Or like using the languages implementation of quicksort is bad because you don't know how efficient it is. IDEs are great because they can provide you with useful information about your project, and they can automate tasks, like refactoring, or setting up the boilerplate code. If you feel like you don't know what's going on, then it's up to you to understand what the IDE is doing. Once you know that, you'll appreciate the value of the tool doing most of the heavy lifting for you so you can focus on the actual work that needs to get done.
In a language like C# I agree with you. You have to use an IDE to get anything useful done. Same with a lot of iOS development, and Java.
But, tools have a major impact on people's ability to work. If you aren't used to using a tool it can be incredibly difficult to get started and feel capable. Telling someone that they're at fault when they're basically forced to use a foreign tool to do their job is disingenuous.
I mean, if you went to work somewhere that used Vim only how would you feel if everyone said you sucked because you had a hard time using Vim? That's basically what you did here.
No, I think you misunderstand. I'll stick with Visual Studio here because that's used as the classic example. Visual Studio does a lot of the heavy lifting when generating boilerplate code for things like Entity projects and ASP.NET MVC projects, and it does hide a lot of those configuration files. However, there is nothing stopping you from looking at those files, and investigating what tools VS is calling under the hood to generate them. The individual is at fault because he's not taking the time to learn what Visual Studio is doing and how C#/ASP.NET projects are organized. That exercise can be done independently of an IDE. Don't blame the IDE, it's like blaming the bread machine for not teaching you how to make bread.
I totally agree, but I tell people who use one at work to not use one at home. It's about being able to adapt to changing market conditions too. If you become dependent on IDEs then when new languages come out you have to wait for someone to make an IDE for that language. If you can also code without one, then you don't have to wait.
I'd argue the same goes for languages, not just tools. At home I like to spend most of my time with Lua, Scheme, and C, and only sometimes Ruby or Python. The less the language does for you, the more you can focus on the concepts and forms.
This is silly. Not every programmer is or will be a professional programmer.
For example, I am a researcher and I use programming in my research projects. I cannot live without using Visual Studio for C#, RStudio for R, SAS Windows for SAS. I am not will never become a professional programmer. I am totally OK with it, because programming is not my profession and I have countless other stuff to learn. I know there are a lot people like me.
This is not a good advice for beginners. At least not for all beginners.
Not sure why you're being downvoted, but I agree with you. IDE's can be very helpful and make things a bit less intimidating at first. Just hitting a "Run" button to make things build and run takes out a lot of the stress. When starting with a new language, that's often just what I want to do at first. I can worry about the nitty-gritty details later. And for researchers and non-programmers, they won't ever have to worry about those details.
The goal of software should be to make things simpler.
A programming language is not an instrument. Its a language that lies somewhere between logic, math, and actual spoken language.
When I was learning guitar, it wasn't filled with analogies like "A guitar is like a broom, you've got to learn to sweep across the strings consistently". They just said, learning guitar is hard, practice and you will get better.
Don't dumb it down for people learning, just say straight out. "Using an IDE will hide the low level things like compilation that you will need to know to be a good programmer".