The Advantages of Eschewing IDEs for Learning

[Epic Tissue]

As a newbie, I have been spoilt with the fact I started programming in Eclipse! Sure, in my class we had tutorials which we wrote on paper with pen but they ended a few months ago. My recent exam went terrible as I was just not used to writing down my code on paper.

My main problem was thinking ahead. On paper, this is so necessary because you don't have room to fit things in or change stuff. With an IDE it is so simple just to launch into a problem without giving it enough thought and just chop and change parts as you see fit.

All my programming from now on will be in a textpad/notepad and command line or even on paper first.

[Tony]

Epic Tissue @ Thu Jun 05, 2008 10:05 pm wrote:

All my programming from now on will be in a textpad/notepad and command line or even on paper first.

Good. Because otherwise people have a tendency of typing out 5000 lines of code, when 20 would have been sufficient.

[r691175002]

While knowing how to use a command line compiler (and how it works) is important, I think that IDEs can have a lot of benefits when introduced early. Say what you will, but autocompletion and api doc integration are lifesavers when working with anything of complexity (Or if you are just unfamiliar). Tracking down the correct import statements for 20-30 classes and typing them out in notepad is suicide.

Whether or not one should be learning on a language with that kind of complexity is still up for debate, but I think that reducing spelling errors, time spent riffling through documentation, and figuring out the right include/import statements is something that takes a good deal of the frustration out of learning to program.

Writing a program in notepad is something everyone should try at some point, but I think it should come once you are comfortable enough with the language to be able to write something basic without spending three quarters of your time figuring out the names of the functions you are looking for.

Proper planning is something that can be done without going to extremes. I almost always throw some flowcharts on paper together or some malformed UML when I am going to code something, but writing code down on paper first is just excessive. (I suppose that if you are doing something like programming challenges its arguable, but anything real and you will be there for weeks).

[apomb]

r691175002 @ Thu Jun 05, 2008 10:46 pm wrote:

While knowing how to use a command line compiler (and how it works) is important, I think that IDEs can have a lot of benefits when introduced early. Say what you will, but autocompletion and api doc integration are lifesavers when working with anything of complexity (Or if you are just unfamiliar). Tracking down the correct import statements for 20-30 classes and typing them out in notepad is suicide.

Most of what you're talking about here deals with concepts far beyond the initial "learning" environment that is being spoken of in the previous posts. What you're talking about does exactly what wtd's main point is stressing the importance of how NOT to learn a programming language. We are not talking about huge projects when it comes to "eschewing IDEs" we're talking about the initial learning of a programming language, understanding what the language can do.

r691175002 @ Thu Jun 05, 2008 10:46 pm wrote:

Whether or not one should be learning on a language with that kind of complexity is still up for debate, but I think that reducing spelling errors, time spent riffling through documentation, and figuring out the right include/import statements is something that takes a good deal of the frustration out of learning to program.

while learning a new language (hell, while learning anything new), mistakes are exactly where you're going to learn the most.

r691175002 @ Thu Jun 05, 2008 10:46 pm wrote:

Writing a program in notepad is something everyone should try at some point, but I think it should come once you are comfortable enough with the language to be able to write something basic without spending three quarters of your time figuring out the names of the functions you are looking for.

I disagree, not entirely, but with the part about having to be comfortable with a language to be able to write something basic... maybe our definition of comfortable with a language are different, but when i write a simple program at first, i WANT it to be simple to write, i dont want to learn where the "compile" and "debug" buttons are in an IDE, i dont want to know how to create a new project with an empty template and precompiled headers. I want to be able to try out some simple functions of the language. Notepad is the perfect place for this.

r691175002 @ Thu Jun 05, 2008 10:46 pm wrote:

Proper planning is something that can be done without going to extremes. I almost always throw some flowcharts on paper together or some malformed UML when I am going to code something, but writing code down on paper first is just excessive. (I suppose that if you are doing something like programming challenges its arguable, but anything real and you will be there for weeks).

No you wont, you'll save a shitton of time getting your ideas down without distractions, when writting code on paper, its not about getting the code right, its about getting the idea cleared up in your own head, sudocode is usually what is written on paper, not actual, formatted and syntax-error-free code.

[btiffin]

Old guy rambling
I'm a CLI fanboy. But, I'm also a huge fan of immersive programming.

polyFORTH development is interactive. Everything you type is Forth and program development is incremental. Each word can be edited into a block (using Forth words) and then tested before the next word is added to the dictionary. Extremely huge and complex applications can be built this way, and the odds are that the quality control, verification and debugging phase is quick and easy. Most of the productive time is programming new features. All polyFORTH systems have LOCATE which allows finding words in block files quickly, and we built an awesome cross reference utility that provided instant access to all words used within a word.

REBOL with it's console is close to this programming paradigm. (While the editor is built in, the actual edits require a swap to "edit headspace".) But REBOL is also highly reflective. Can't remember what the argument order is for a function? HELP and SOURCE is right there at your fingertips while developing.

C now has the uber cool Ch environment. Interactive C (and a little C++ just to sweeten the pie) with the Ch console double tasking as a *nix shell with access to the Unix paradigm of lots of small utilities that all do one thing, very well, that can be glued together with pipes and scripts.

Those are my favourites.

Forte for Java was my first serious use of an IDE (I don't count VB or VC++; while I respect a coders choice to use VB, I personally view VB as a toy and VC++ 1.0 was so much bloat that I was turned off by it, and just used the CLI tools unless forced to use the IDE to handle the overly bogus resource management). This is personal, but I usually spent more of my day playing with the Forte IDE features than programming. That slowly changed to more code than "button exploring" but I didn't feel overly productive for many months (but I'll admit to having a lot more fun than I usually expect from a working day).

Wrapping up this ramble; imho an interactive and reflective development console is #1, CLI is #2 and an IDE is a distant third. IDEs require far too many "brain space" modes for a productive development session. Every feature of an IDE requires losing the immersive nature of thinking in the programming language at hand.

But with the topic of the post being IDEs for Learning I'd have to say that an IDE at least offers hints to where to find information and can help come to grips with library (a huge part of mastering a language) and project setup. After a programmer comes to grip on other ways to find out about features, a CLI allows a lot more focus and the IDE should only be used when absolutely necessary or those rare times when work seems like too much trouble and "I don't want to work, I just want to bang on the drums all day".

And and lastly; GNU/Linux is an awesome "IDE" and it's free.

Cheers
end ogr

[apomb]

Quote:

And and lastly; GNU/Linux is an awesome "IDE" and it's free.

now This kind of IDE I support

[Tyr_God_Of_War]

McKenzie @ Wed Jul 20, 2005 2:56 pm wrote:

My biggest problem is that at my current school board they don't allow students access to the shell because they fear that the students will abuse the privilege.

Same here, mostly. They've blocked cmd.exe, but not batch files or command.com. I got msys as part of the devkitpro package, so I can still use make and familiar *nix shell commands instead of Windows ones. It is not blocked, as it's running from my usb stick.

I also use programmer's notepad, which also came with devkitpro (Windows installer). It's nice to have it handle some of the makefile stuff automatically.

[Insectoid]

EDIT: Damnit, img tags didn't work

[Juliett78]

1of42 @ Sat Jul 16, 2005 3:37 pm wrote:

While I'm starting to see what wtd means by pitfalls, I honestly think a lot of these issues are very contrived. The last time I saw someone who thought a .java or .cpp file was some magic format was... never. Honestly, if you're smart enough to write a program, these things should be blatantly obvious.

Hi guys
While some experienced programmers may find the mentioned issues trivial, it's important to remember that not everyone starts at the same level of expertise. Beginners, especially, may encounter these pitfalls and misconceptions. free fire name style

[pslhit]

r691175002 @ Thu Jun 05, 2008 10:46 pm wrote:

Candy CrushWhile knowing how to use a command line compiler (and how it works) is important, I think that IDEs can have a lot of benefits when introduced early. Say what you will, but autocompletion and api doc integration are lifesavers when working with anything of complexity (Or if you are just unfamiliar). Tracking down the correct import statements for 20-30 classes and typing them out in notepad is suicide.

Whether or not one should be learning on a language with that kind of complexity is still up for debate, but I think that reducing spelling errors, time spent riffling through documentation, and figuring out the right include/import statements is something that takes a good deal of the frustration out of learning to program.

Writing a program in notepad is something everyone should try at some point, but I think it should come once you are comfortable enough with the language to be able to write something basic without spending three quarters of your time figuring out the names of the functions you are looking for.

Proper planning is something that can be done without going to extremes. I almost always throw some flowcharts on paper together or some malformed UML when I am going to code something, but writing code down on paper first is just excessive. (I suppose that if you are doing something like programming challenges its arguable, but anything real and you will be there for weeks).

You bring up valid points regarding the benefits of using Integrated Development Environments (IDEs) when learning and working with programming languages. IDEs provide useful features such as autocompletion, API documentation integration, and error checking, which can greatly enhance productivity and reduce certain types of errors.

Autocompletion can assist in finding the correct syntax, function names, and class members, saving time and reducing spelling errors. API documentation integration within the IDE allows for quick access to information about classes, methods, and parameters, facilitating the learning process and helping developers understand how to use unfamiliar libraries or frameworks.

Moreover, IDEs often provide features like code navigation, refactoring tools, and debugging capabilities, which can contribute to a smoother development experience and make it easier to understand and maintain complex codebases.

While it's beneficial to understand the underlying processes and mechanics of command line compilers, IDEs can provide a more user-friendly and efficient environment, especially for beginners or when dealing with larger and more complex projects.

[wtd]

I maintain my position years later.

One need only take a look at sites like Stack Overflow. There is a never-ending stream of questions about configuring IDEs. Intro CS should teach how to think about solving problems and not how to configure VS Code or Eclipse.

To clarify, I am not saying IDEs are always bad for everyone, but at an intro level, they are harmful.