On Friday, 24 February 2012 at 05:05:29 UTC, James Miller wrote:
You seem to think that there is "Notepad" or Visual
Studio/eclipse,
when in reality there is a sliding scale, from using cat to
output to
a file to using, well Eclipse or VS. But there are points along
the
way, like Jonathon, I'm a (g)vim user, I tend to develop in
gvim and
do quick edits in vim (tiling window manager, I don't like the
switch
from full-screen to half-a-screen then back again), I have
tried all
sorts of other systems and eventually just worked my way back
to the
terminal. My ongoing quest for productivity has led me to
believe
that, unless you want to be tied to a technology, back to
basics is
the best way.
That's analogous to saying that you don't want to depend on a
lighter since you can make your own fire by rubbing a stone with
a wood stick. A lighter does tie you to a certain technology but
loosing the lighter doesn't make for more productivity. Misuse of
the tool or using the wrong one sure could hamper productivity
but that's hardly the fault of technology.
I personally believe that any set of tools should be made
thinking
about the use case: "What if this person was developing using a
Tektronix 4014?", I'm not saying that we should still be coding
to 30
year old terminals, but the idea is that somebody might not
having a
gui should not immediately be a blocker. This has been Windows'
Achilles' heel for a while, many products don't work without a
gui,
and therefore are difficult - or impossible - to script. If you
can
provide a programmatic interface to your system, then you have
just
allowed a ton more products to be made, at no extra cost to
you. Clang
has built-in support for auto-completion and syntax analysis
and the
front-end is even nicely packaged into a library, so I now have
C/C++/Objective-C, context-aware, accurate completion in vim,
through
the vim plugin clang-complete, this was not made by the people
at
Clang, they just exposed the functionality (by the way, XCode
uses the
same system, and Code::Blocks is moving their code-model to it
too).
The above regarding MS is incorrect. MS has lots of automation
and is far better at it than *nix systems are. Its Powershell is
superior to the *nix "everything is a file" ideology and there
were several attempts to copy the concept to *nix with Python and
Ruby.
Programming a craft as much as it is a process. I tend to liken
it to
carpentry, you have set steps, you design and plan and build
etc, but
there's creativity there. As such, programmers (I've found)
tend to
pick an environment that suits them best. I use a minimal
system that
I can configure and hack to my heart's content. My colleague
uses a
Macbook pro that he never shuts down. The designer here uses a
Macbook
Air. And we all work fine, there is no "One True Way" to make a
chair,
why should there be one for writing a program?
My point is that the tools that programmers use, like compilers
and
linkers and parser-generators and build systems and deployment
tools
and source control and x and y and z and .... are going to be
used by
a wide range of people, in a wide range of environments, for a
wide
range of purposes, so they should keep in mind that maybe you
/don't/
have a certain tool or feature available. So you make sure that
the
experience at the lowest common denominator, a vt100 terminal,
is
acceptable, maybe not perfect, but good enough, then you build
from
there. If that means that D is geared towards less typing, then
good,
especially if you can do the extra typing and not break
things. It
/is/ possible to make everybody mostly happy, and that is by
aiming at
the people using `cat`* to program and hitting the people using
VS
along the way.
* Programming using `cat` is not recommended.**
** Even though /real/ programmers use `cat`
--
James Miller
I disagree. Simply put:
+---------+ +---------+
| Magic | | comfort |
| happens | | zone |
| here! | +---------+
+---------+
Magic cannot happen here ^.
