As a learner should I use an IDE?
closed account (3CXz8vqX)
~TheIdeasMan well the question was actually whether IDE's are good for beginners... it's an open ended question and doesn't have a right or wrong answer. As for the sub question about bugs, it's not a troll I just don't agree with the restrictions being placed upon the definition, I don't understand why and I don't see the point. I'll repeat: An error is an error is an error.
| Ravenshade wrote: |
|---|
| An error is an error is an error. |
On a completely unrelated note, a bug is a bug is a bug.
A compilation error is not an execution bug, because there is no execution.
Last edited on
They are programmer errors. They are not compiler errors. There is a massive difference.
The most common shortening of "compiler error" is "error".
The most common shortening of "programmer error" is "bug".
The most common shortening of "compiler error" is "error".
The most common shortening of "programmer error" is "bug".
Last edited on
Give up guys. Let me think what he wants. He's obviously too stubborn to listen to the half dozen people telling him he's wrong.
> Project - Add Existing Files - Select all files
Again, ¿what's a project?
I'm just saying that the idea is not intuitive.
> Whatever tool they are using, it's their tool, so they should RTFM and learn how to use it.
>> How does this not apply to IDEs as well?
Whatever tool.
It was aimed to both sides.
Again, ¿what's a project?
I'm just saying that the idea is not intuitive.
> Whatever tool they are using, it's their tool, so they should RTFM and learn how to use it.
>> How does this not apply to IDEs as well?
Whatever tool.
It was aimed to both sides.
Last edited on
| ne555 wrote: |
|---|
| Again, ¿what's a project? I'm just saying that the idea is not intuitive. |
closed account (3CXz8vqX)
I beg to differ that projects are intuitive. Having a collection of files is intuitive but a project tends to be a tad more than that and hard to grasp unless you understand previously how the files link together.
~L B Still errors! If there's any practical difference later on, then I'll change my mind but as it is you're just telling different breeds of cats apart and to me a cat is a cat. ]
Please note that I have had very very little formal education/training in C++ =3 so I get to think how I want to think.
~L B Still errors! If there's any practical difference later on, then I'll change my mind but as it is you're just telling different breeds of cats apart and to me a cat is a cat. ]
Please note that I have had very very little formal education/training in C++ =3 so I get to think how I want to think.
Last edited on
| Ravenshade wrote: |
|---|
| I beg to differ that projects are intuitive. Having a collection of files is intuitive but a project tends to be a tad more than that and hard to grasp unless you understand previously how the files link together. |
| Ravenshade wrote: |
|---|
| Still errors! If there's any practical difference later on, then I'll change my mind but as it is you're just telling different breeds of cats apart and to me a cat is a cat. |
| Ravenshade wrote: |
|---|
| Please note that I have had very very little formal education/training in C++ =3 so I get to think how I want to think. |
| If there's any practical difference later on, then I'll change my mind |
There's a practical difference in this thread:
- You were asked a question ("How do you debug?")
- You didn't understand the meaning of the word and therefore answered it nonsensically.
- 3 of the people you were talking to got confused and had to clarify what they meant / explain the meaning of the word / rephrase the question.
The entire point of having definitions for words is so that other people know what you mean when you use them. If you are refusing to accept the definition that everyone else uses for a word... then why bother to use the word at all? Why not just call them "flibbityjibbits"?
closed account (3CXz8vqX)
~L B That's the point L B, from things that I have read so far, apart from on this forum, there has been no real differentiation between a Lion and a Domestic cat as you put it. It might actually be a better comparison to use Savannah Lions and Mountain Lions, they're both threats but of different severities and if severity is the only difference, then in the end it just means that the program isn't doing what you want it to do.
If someone talks about a bug I simply take it to mean that there's something wrong, the first thing I check, is...does it compile, if it compiles, what doesn't work, why doesn't it work...solve, repeat. I have seen 'nothing' that requires me to have a separate definition of a Compiler Error and Runtime Error so I call them both bugs.
I expect to learn through the scientific method...trial and error. If it doesn't work the first time, try something else instead until it does work. How do you think computers were invented in the first place?
~Disch debugging is done in the same damn way as you solve a compiler errors. You go through the code again and correct it the fault nine times out of ten it was the programmers fault anyway. It wasn't nonsensical at all.
If someone talks about a bug I simply take it to mean that there's something wrong, the first thing I check, is...does it compile, if it compiles, what doesn't work, why doesn't it work...solve, repeat. I have seen 'nothing' that requires me to have a separate definition of a Compiler Error and Runtime Error so I call them both bugs.
I expect to learn through the scientific method...trial and error. If it doesn't work the first time, try something else instead until it does work. How do you think computers were invented in the first place?
~Disch debugging is done in the same damn way as you solve a compiler errors. You go through the code again and correct it the fault nine times out of ten it was the programmers fault anyway. It wasn't nonsensical at all.
| Ravenshade wrote: |
|---|
| That's the point L B, from things that I have read so far, apart from on this forum, there has been no real differentiation between a Lion and a Domestic cat as you put it. It might actually be a better comparison to use Savannah Lions and Mountain Lions, they're both threats but of different severities and if severity is the only difference, then in the end it just means that the program isn't doing what you want it to do. |
| Ravenshade wrote: |
|---|
| ~Disch debugging is done in the same damn way as you solve a compiler errors. You go through the code again and correct it the fault |
No, Debugging and fixing compiler errors are two very different things. That is what we've been telling you for the entire thread.
But yes... if you generalize the steps enough then they become the same thing.
By that logic... programming and accounting are the same thing. They're both just looking at a screen and typing on a keyboard.
| It wasn't nonsensical at all. |
Maybe not to you, but it was to me. And to several other people.
Did you not notice that like 3 people responded to your answer with something like "I don't think you understood the question"?
But whatever. This thread has gotten retarded. I have a hard time believing that anyone could possibly be as dense as you're being. You're obviously trolling, and I'm going to stop feeding you now.
Last edited on
| Ravenshade wrote: |
|---|
| If someone talks about a bug I simply take it to mean that there's something wrong, the first thing I check, is...does it compile, if it compiles, what doesn't work, why doesn't it work...solve, repeat. I have seen 'nothing' that requires me to have a separate definition of a Compiler Error and Runtime Error so I call them both bugs. |
If it doesn't compile, then there's no way to tell if there's a bug or not, because you can't even run the program.
| I expect to learn through the scientific method...trial and error. If it doesn't work the first time, try something else instead until it does work. How do you think computers were invented in the first place? |
I'm not sure that "trial and error" is a recognised program design methodology. It certainly isn't an efficient method.
| ~Disch debugging is done in the same damn way as you solve a compiler errors. You go through the code again and correct it the fault nine times out of ten it was the programmers fault anyway. It wasn't nonsensical at all. |
If the programmer wrote incorrect code, simply looking at it again and again is no way to solve it. More to the point, a program which compiles and runs without apparent error may still contain many bugs.
A debugger isn't guaranteed to solve all the world's problems, but it can highlight where control is passing via an unexpected path through the program, or when variables have unexpected values. It's a tool, a valuable one. I've used a debugger when a program had no faults whatsoever, in order to verify that the code was executing according to the way it was intended. In that respect it offers something which no amount of staring at the code can give.
Topic archived. No new replies allowed.