Does Visual Studio Rot The Mind?
I like visual studio, my main reasoning is that it helps me develop a mental overview of what I am doing and that seems to integrate well with memory when returning to projects after some time. It also cut down the time it took to become, what I'd describe as, a "functional programmer".
I think the big difference here is that some people are 'hackers', others are 'programmers', and the rest are 'software engineers'.
Next up: Horse Power vs Miles/Gallon vs Transportation Utility
Next up: Horse Power vs Miles/Gallon vs Transportation Utility
Quote:Original post by Name_Unknown
Personally I find Emacs provides almost all the same things, but it requires more understanding of your tools than Visual Studio so it's harder and people don't like it.
I once had to tell my professor how to set #include directories in Visual Studio because he didn't have a clue how. He had knowledge in emacs but he was using Visual Studio. Who knows his tools better, me or him?
Use what you are convenient at. Arguing which tool is better is like an argument between a caveman and a gunman.
Quote:Original post by OluseyiQuote:Original post by Name_Unknown
Ask most people around here about Makefiles, how to use the linker, compiler options, etc and they don't have a clue. They depend on Visual Studio to do it for them. That's not good, a developer should understand there tools and how to use them from the command line as well.
Why?
In some ways, its necessary to know the underlying procedure in order to find problems and fix them if anything goes wrong. Its really not a black and white issue though, and atleast at my school, we are taught those basic things without relying on IDEs. Interestingly though, when I first started using these tools in VS I almost always messed up and had to learn the 'tricks' in dealing with certain circumstances. So really you will have to deal with learning the underlying mechanism in one form or another. If you never have to, then thats even better, because deadlines do not take these minor issues into consideration but your efficiency sure goes down the drain when you come across some.
At the end of the day, the people who can do stuff faster will be more successful.
Quote:At the end of the day, the people who can do stuff faster will be more successful.
Amen. A few years ago, when I was creating Java apps for my study with notepad and Javac, I might have agreed 100% to the argument of knowing all the details of the compiling/packaging/deployment process. I have come to realize however that the productivity argument is far more important than knowing how to use all the (command line) tools available on a software platform. Hurray for VS 2005 refactoring, I really missed that coming from JBuilder :)
Like the comparisson between Emacs and VS, you could also compare "compiling your Java source code from the command line, sticking it in a jar, manually putting it on your webserver and typing the HTML to load it" to "clicking the deploy button in VS 2003". I think it's safe to say I know a lot about Java development and deployment, but in the end the VS way is still faster.
A good IDE actually should encapsulate these details, offering you a wealth of functionality and knowledge with a simple button press/wizard/intellisense/whatever. If you deny the value of this, there's little point in arguing since then you might as well deny the usefulness of Windows/Gnome/Anything more than a command line. After all, it provides the same functionality and you get to know the underlying structure perfectly well. Now that's an analogy ;)
Besides, any serious developer will know where to look if more information on the underlying process is needed. Javac/CSC/Make aren't that complicated if you take the time to study some materials on them.
VS.Net 2003 IDE most annoying part is that the F1 help on Win32 API function where it always brings you to an equivalent function name MFC class methods.
Quote:Original post by Yann L
And the worst of all: he loved Doxygen. I don't kid you.
Why is it worst of all? Doxygen isn't that bad
Personally i don't use it because i find it rather pointless to create documentation that you'll never read because you can find it in the code itself, but it's not *that* bad.
Quote:Original post by Yann L
Little story that happened not so long ago: we had a couple of programming entry level positions open in our company. We advertised the jobs, which primarily targeted CS students for their first job in the industry.
There was this guy. Linux nerd, GPL, Stallman, Slashdot fan, blahblah. I had the 'pleasure' to interview him. God, I don't know why I always get those. I suspect that it is an evil plot of the HR dept who specifically target these people towards me, because they know how much I hate them...
Anyway, his university diploma was pretty good, but his resume was a little unclear about his experience with common industrial development tools. I asked him about it, and it turned out that he never used an IDE in his entire life. He was using VI (!) and command line GCC exclusively. Of course only plain C, because C++ and C# are sooo inefficient. Instead, he was praising the efficiency of Java, because "it could be JIT compiled !". Yeah, whatever.
He went on about how MSVC was the work of the devil, and how incredibly easy it was to manage enterprise style projects by using VI and commandline compilers. As a versioning system, he was obviously using command line CVS (what else).
And the worst of all: he loved Doxygen. I don't kid you.
I completely lost any remaining faith in our computer science educational institutions after this incident.
Well, unfortunately, CS programs are getting worse in this area (not the anti-MS pro-GNU part), the part where there is absolutely no experience actually doing anything. Most of my CS classes have focused on design of software and agent architectures, and software engineering (design & process, of couse, little coding or tools used). We have never used version control, an IDE, or actually even had to write anything that did more than print some text messages to the screen, and we almost never will in the whole undergrad program.
They claim that they do this because industry asks them. I don't believe that for a second - I would imagine that industry is looking for people who can actually build something useful or contribute to a large project in some way.
Quote:Original post by etothex
Well, unfortunately, CS programs are getting worse in this area (not the anti-MS pro-GNU part), the part where there is absolutely no experience actually doing anything. Most of my CS classes have focused on design of software and agent architectures, and software engineering (design & process, of couse, little coding or tools used). We have never used version control, an IDE, or actually even had to write anything that did more than print some text messages to the screen, and we almost never will in the whole undergrad program.
I also made that observation, unfortunately. I don't know how it is over in the States, but here in France (and also other parts of Europe), it seems that CS students are getting more and more separated from reality. They're all focussing on old school Unix style development, and live in their happy little academic GNU world. Until the real software industry hits them really hard. No wonder that the unemployment rate amongst software engineers is so high over here.
If you want to use VI, emacs or *gasp* Doxygen for your own hobby projects, then there is absolutely no problem with that. But don't expect to use them in the industry. As Promit has very well said above, it's all about productivity - time is money. And VI is not a productive tool, it is a horribly inefficient piece of software. At least when used in an industrial context - quick access to information, error minimization, team integration, rapid application development and deployment. I had to use VI in the past, and God, I'm so glad that these days are over.
In the end, we're talking about software ergonomics here. What is the best and most efficient interface between human and machine in the context of application development ? Individual answers will vary widely, but an IDE such as the MSVS one is definitely a huge step ahead of VI and handwritten makefiles. No, it's not perfect. But as everything in the IT sector, it is constantly evolving into something better. While MSVS might not be the holy grail, VI & friends are dinosaurs.
Now, someone above said that pure command line compiling is still used in the industry. Of course, this is true. There's a lot of legacy processes in this on one side ("don't change a running system") and obviously custom build systems on the other side. The former are being gradually phased out, the latter are sometimes a necessity. But nothing prevents one from integrating those build systems into existing IDEs.
Quote:
Why is it worst of all? Doxygen isn't that bad
Yes, it is. Seriously, if there is one software package I really, really hate with a passion, then Doxygen :)
Quote:Original post by OluseyiQuote:Original post by Name_Unknown
Ask most people around here about Makefiles, how to use the linker, compiler options, etc and they don't have a clue. They depend on Visual Studio to do it for them. That's not good, a developer should understand there tools and how to use them from the command line as well.
Why?
And while we're making unfounded and unsubstantiated broad assertions, anyone who inserts manual line breaks into the textarea when posting a GDNet thread either because they don't or can't understand free flowing text wraparound is a moron.
No offense. It's just an analogy.
No offense taken, why would I be offended by a retard
who can't use make?
who doesn't know
how to use
their compiler
or
linker
on the command
line?
who is
dependent
on a toy making software company's software
to develop
and a toy operating system
which stole it's ideas
directly
from the BSD lite kernel
anyways?
no offense
it's just an
analogy.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
