Re: Any tips?
On Saturday, March 16, 2013 1:58:14 PM UTC, Nick Keighley wrote:
On Mar 13, 3:55 pm, James Kanze <james.ka...@gmail.com> wrote:
On Saturday, 9 March 2013 11:34:28 UTC, Nick Keighley wrote:
On Mar 6, 5:25 pm, James Kanze <james.ka...@gmail.com> wrote:
I don't know. I use Visual Studios 2012 (at present) under
Windows, because that's my employers standard; I've always used
vim, bash and makefiles under Unix. And the vim, bash and
makefiles environment is far more productive than the Visual
Studios environment.
really? I've used both (well not vim). I've also used Qt Creator. I'd
like to see how you measure "productivity"
Getting working code out of the door. Actually, creating and
maintaining working code effectively, for a complete definition
of working code (i.e. maintainable, tested, documented...).
and what evidence do you have that this is easier with vim/bash/make
than VS? Just saying so isn't enough. As I say I've worked in both
environments I don't see the massive disparity you claim. I think
there's a little bit of unix bigotry.
Personal experience. And I do know Windows and VS now.
Originally, I put my lower productivity under Windows down to
the fact that I wasn't familar with it. Now, it's gotten to the
point where every time I want to do something, I can't find the
proper support in VS, and none of the so called experts seem to
know how to do it either---they often seem surprised that such
things actually can be done.
If you're just starting programming,
something like Visual Studios is probably a pretty good idea, so
you don't have to learn everything at once, just to compile
hello world.
even compiling hello world is non-trivial with VS!
You mean because you have to create a solution, with a project?
yep. And turn off a bunch of MS extensions and explain you want to use
ASCII and I think a couple of other things. Out of the box VS isn't a
C compiler.
Out of the box, neither is g++, nor Sun CC. The difference is,
perhaps, that in the Unix world, you expect to have to actually
read the compiler documentation, and determine what options you
need for your project. VS pops up with two default
configurations (Debug and Release), neither of which really
corresponds to what you might want to do in most cases. (My
personal libraries are developed with with something like eight
different configurations: optimized or not, profiling or not,
multi-threaded or not.)
For anything more complex, the fact that you don't have to
write a makefile is a win for a beginner.
not just beginners
It's a lot like C++. When you being, you're overwhelmed by how
much you need to know. With a little experience, however,
you've got a good tool set for your style of programming, and a
number of more or less standard idioms, and you can knock out
complex programs in very little time.
For production code, of course, the fact that you can't really
create arbitrary rules, like you can in a makefile, is
a problem. As is sharing "projects" between different
solutions, which use different compiler options. I've done it,
but it involves editing the project files by hand; at that
point, you're better off using makefiles, because the higher
level makefile can pass explicit information down to the project
file. (With VC++, you have to create rules conditioned on the
solution name.)
But if you are already an experienced programmer,
it's probably worth your while to learn how to use more powerful
tools; there's just so much you can't do in Visual Studios (or
in any of the IDE's I've used under Linux, but I've not tried
any new ones recently).
like?
If you limit yourself to the IDE, just about anything useful.
Try creating a project in which several different sources are
generated from other programs. There's special mechanism for
the case where a single source and header are generated by
a single tool (e.g. lex and yacc), and you can have one (but
only one) pre-build step. But the build system doesn't
understand any dependencies created by the pre-build, and if you
want two or more operations, you have to wrap them into some
sort of script. (The fact that the build system decides what
needs recompiling *before* doing the pre-build is a serious
error, since the purpose of the pre-build is normally to
regenerate some files.)
ok. I think you have me! The last VS project I worked on we avoided
such things (probably because it was hard). The only thing that did do
this seemed to rebuild everytime even then it wasn't necessary.
*Not* generating significant amounts of code by machine results
in an enormous loss of productivity. I'd have to go back 25 or
30 years to find a project in which there wasn't a lot of
machine generated code. Why should I waste my time doing things
the machine can do better?
If I want to process text I use Perl and tend to use it as a
scripting language as well (bash syntax drives me nuts) but VS seems
fine for most stuff.
Bash syntax is a bit special, but the real problem is that the
individual tools aren't always coherent. You need to learn
several different variations of regular expressions, for
example. It's still an order of magnitude better than Perl,
really? What tools? sed and awk and such like?
Sed, awk and grep are the three standard ones. Each of which
has a subtly different form of regular expressions. (In the
case of grep, of course, there's grep, egrep and fgrep, each
with a different version of regular expressions.)
Once it gets too complicated to just type in at the command line
(say after about 10 lines of code), I'll switch to Python. It's
a bit of a shame that you need boilerplate to get os, sys and re
(since I almost always need them), and having to explicity loop
over each line (rather than implicitly, and is sed and awk)
makes for an extra line or two, but on the whole, it still
works pretty well.
Under Windows, I'll also use Python sometimes when C++ would be
better, simply to avoid having to create an extra project, and
project dependencies, just to get an .exe to generate my code.
--
James