91–100 of 255 posts
I tend to agree, but I wonder how many in the "IDE bad" camp would agree that in order to obtain your drivers license, you must pass the drivers test on a manual transmission?
Earlier quoted context omitted.
I agree that many developers are not very adept with tooling, but is that because they don't use the CLI? Or is it just that they aren't interested in those parts of software engineering? Eclipse is a tool too, and not a simple one either.
IDEs are convenience layers, compilers are essential abstractions - if you don't know how it works underneath the GUI layer you will get stuck really fast and won't be able to troubleshoot when you eventually run in to inevitable problems with IDE, build, compiler.
Earlier quoted context omitted.
I agree that many developers are not very adept with tooling, but is that because they don't use the CLI? Or is it just that they aren't interested in those parts of software engineering? Eclipse is a tool too, and not a simple one either.
The author is specifically talking about students. The emphasis at this stage plays a key role in whether they'll have that interest or not. Knowing is a prerequisite to developing interest.
I take exception to this line of thinking. Students should not be using the command line for programming. I believe that forcing students to learn to use command line tools is the reason why so much software has such horrible user experience. They learn that users don't matter unless they've steeped themselves in the arcana of each particular program and have practically become programmers themselves.
> Second, it catches some basic mistakes and allows the student to defer learning about the finnicky language requirements that aren’t deemed core to the curriculum, like imports and file naming requirements.
I had the exact opposite experience. At university, they sat us down at a Unix shell with almost no instruction on the shell or the compiler. We spent so much time learning the finicky shell requirements (and which we had no clear understanding were part of the shell and not the compiler itself or something else), that we were sidelined from understanding what the compiler was telling us or how it worked. You'd run your program and if it gave you an error 11, well, you just read and re-read it until you noticed something off.
Nowadays with an IDE and a static analyzer, it can show my code and show the exact path of execution that will lead to an invalid memory access before I've even run it. Students can learn to find problems themselves because it's laid out right in front of their eyes in relatively-understandable java or C or whatever language they're programming in. They don't need to worry about, "Oh when I compile on this machine, I have to specify the -I argument to the compiler for includes, but on machines I actually use in real life, I don't have to specify anything because it finds all the files I'm actually using because I put them into the IDE myself and can see their relationships."
> it’s crucial to introduce these inconvenient details eventually.
Why? If I'm going to be downloading my IDE from the Internet or an App Store why the heck should I ever learn fiddly Unix commands? I'm writing GUI-based applications. I don't need to understand any of that crap if I don't want to. It's like saying you can't be a taxi driver if you don't understand how the carburetor works. Really? My job is to drive the car around, not to fix it. I know a good mechanic who can do that if the need arises. If they want to learn it, then all the better, but it shouldn't be a requirement.
> What they can’t do, unless they’ve figured it out on their own, is operate a computer outside of the confines of the IDE they’ve been taught.
On the contrary, I had no problem operating the GUI-based computers of my day. It was the bizarre, often contradictory commands in the Unix shell that baffled me. Their names were often stupid puns, their "help" pages did no such thing, and I wasted years learning a bunch of stuff that ended up not being very helpful in the real world.
> When students have only ever programmed in Java using some bespoke learning library provided by their professor, it will take them much longer than necessary to figure out other languages, other libraries, and other approaches.
That has nothing to do with IDEs. That has to do with a deficient teaching environment, and is the exact same problem I described above, which sounds like what the author is advocating.
> Teaching someone to use git is very difficult if they’ve never been taught that a file is an logical unit composed of bytes and metadata.
No, teaching someone to use git is very difficult because it was designed to be difficult because the self-absorbed creator thinks that people should have to suffer to become good programmers. It's just sadistic.
> Students need to know how to use computers before they can program them in a serious way.
I agree, and what the author is proposing sounds like the opposite of that to me.
> After the first foray into programming, take time to teach students about the UNIX command line.
Ugh. I disagree strongly with this sentiment. CS students need to get away from the mentality that Unix is the be-all-end-all of operating systems and programming environments and the quicker that happens the better in my opinion.
> ... it insulates the student from the javac command line program, and the command line environment itself Such a misguided article. The Java language has (quite literally) nothing to do with `javac`. In fact, there's a lot of other compilers out there. Taking a Java class should not focus on the intricacies and weirdness of Java compiler command line interfaces. It seems pretty amateurish to argue in favor of it. C…
I also think that Java is perhaps the worst possible choice for that.
It's a language created with the "build once run anyway" mentality that tries to abstract away the system, it's the poster child of languages married to an IDE, and verbose to the point that forcing people to write java code without autocompletion features probably violates the Geneva convention.
At this point in time if you want your students to learn about tooling it would be more useful to teach them to use chrome's JavaScript console than to teach them to use a Java compiler through the command line.
Much less mental overhead and less things to worry about on the Linux command line. Plus, I can do more with the commandline tools.
I think students in general will be more versatile if they start with the command line, and then graduate to Eclipse. That way, they'll realize what they lose and gain in an IDE.
I'm not sure I agree much with this. When I first started learning Java I had six or seven years of programming experience and I still found dealing with matters of classpath and javac remarkably complicated. I had things down well enough with the tools I used before, but it all seemed so foreign in the Java world. And to this day I find junior devs struggle with the same things unless they have a maven/gradle projec…
Actually I agree for the Java world here. Thanks to the design of Java and many Java libraries you cannot write a little more complex Java code from your mind. Even importing all this nested OOP libraries is complicated without an IDE. For me Java is really a language which is impossible or too time consuming to master without a good IDE. Working for many years in the python world professionally some people are still…
For other languages, e.g. go, which i currently like, I don't use an IDE because I don't feel like I need one.
In my opinion IDEs are often just a crutch for bad languages and I can understand the sentiment in the article, but yeah, java.
> ... it insulates the student from the javac command line program, and the command line environment itself Such a misguided article. The Java language has (quite literally) nothing to do with `javac`. In fact, there's a lot of other compilers out there. Taking a Java class should not focus on the intricacies and weirdness of Java compiler command line interfaces. It seems pretty amateurish to argue in favor of it. C…
I strongly disagree. A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers because they didn't know any tooling. They couldn't compile, run, test, or source control their code if the professor didn't set it up for them. Yes, tools change, but the knowledge from one tool is almost always transferable. Once you're comfortable on the CLI and understand t…
I’d agree that some focus on that in CS programs would extremely valuable. Maybe things are better now, but when I went in 2008-2012 git wasn’t even mentioned and basically all tooling was learned on your own.
Earlier quoted context omitted.
IDEs are convenience layers, compilers are essential abstractions - if you don't know how it works underneath the GUI layer you will get stuck really fast and won't be able to troubleshoot when you eventually run in to inevitable problems with IDE, build, compiler.
What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler, or that it's been around for longer? A GUI isn't necessarily just calling CLI apps in the background, it could be using programmatic interfaces too.
It's not simpler! It's way more confusing to figure out that your make file told your compiler to run a command with some unknown set of obscure options that are causing an error than to just have the IDE pop a dialog and tell you in plain words, or better, not even let you set an option incorrectly in the first place.
But I greatly disagree about students using IDEs on languages like Java. Getting familiar with debuggers, stepping around, that's absolutely a necessary skill--unless you want to go into stdio, or echo based debugging (which is what I'd do with the languages above).