On Sat, May 19, 2012 at 04:10:29AM +0200, Mehrdad wrote:
> On Saturday, 19 May 2012 at 01:28:32 UTC, H. S. Teoh wrote:
> >You must be using Emacs with a GUI.
>
> No, I told you I hate Emacs. :P
> I've seen *other* people do it, and it's horribly slow.
Well, let's just say that Emacs and gui in a single sentence is just a
recipe for pain. Especially when you're talking about doing it over the
network.
[...]
> >Which is what I mean. GUI's are useless across an SSH connection.
>
> Ah, ok. That makes more sense than "GUIs are slow over an internet
> connection".
> Yes, SSH wasn't designed for GUIs (or the converse), so of course
> it's slow.
Although, to be fair, the reason for much of this slowness on *nix
systems is that X11 is one phat protocol. Trying to to run X11 over a
remote SSH session is like trying to parse a 5MB XML file on a 386 with
512k RAM instead of just reading the data directly from a binary file.
It's just _asking_ for pain, and lots of it.
> Trying to force GUIs onto *nix systems is like trying to force a
> command-line tool on Windows... doesn't exactly work the way it's
> supposed to, and it gives you the wrong impression.
Well... I think a lot of it is that people are used to the way Windows
work, and they imagine that _all_ GUIs must work just like that. Which
is not true.
On the flip side, X11 was designed in a bygone age, and its age is
showing (and rather badly at that). It paid lots of attention to little
trivial things that are no longer applicable in today's systems, and as
a result performs poorly over the internet. There have been efforts to
design a more modern windowing system, but none of them have caught on
just yet. One day it's bound to happen, though.
[...]
> >Oh? It's called "rename the method and recompile, get 50 pages of
> >compile errors, pipe it to a grep command that extracts the filenames
> >and line numbers, use sed to transform that into a sed command that
> >automatically substitutes every instance of the matching identifier
> >on the given files/line numbers".
> >
> >See, I told you I was a command-line freak. :-)
>
>
>
> Yes, that's clever. :P **EXCEPT**:
>
> 1. Compilers (cough, DMD?) generally limit their output to a few dozen
> errors, so your '50 pages' is kinda off. :P But yea, you could just
> loop until it works.
>
>
> 2. Okay, so that's clever. :P Now tell me what you do when you have
> dozens of lines in your source file like
>
> @property auto length() { return _range.length; }
>
> and you want to rename the field 'length'? How do you prevent the
> second one from getting renamed?
Substitute "length(" with "size(" instead of just "length" with "size".
Problem solved. :-)
> Or say you have
>
> @property auto back() { ... }
> @property moveBack() { assert(0, "Cannot move an element from the
> back!"); }
> auto popBack() { } // Remove an element from the back
>
> and you change the name of the property 'back' to 'last':
>
> @property auto back() { ... }
> @property moveBack() { assert(0, "Cannot move an element from the
> last!"); }
> auto popBack() { } // Remove an element from the last
>
> Notice something funny?
Again, you rename "back(" to "last(" instead of "back" to "last". This
is a trivial mistake that anyone who's used vim for at least a year
would've known without thinking twice. :-)
> Worse yet, no way in hell that a command-line tool would tell you your
> documentation is messed up. :P
Oh yeah? And what about when documentation mentions the old name of the
method? In which case you *want* to rename it. :-)
> >Well, I _did_ demonstrate how to do it above, given the proper tools
> >and shell support. :-) It's a bit clunky, but hey, it works. And if
> >you get further compile errors, just look those up (using suitable
> >combinations of grep/sed) and undo the wrong substitutions. Just two
> >steps, and you're done.
>
>
> You're done? Or so you think.
> See above.
I did say it's clunky. But it's also a trivial case that one quickly
learns and remembers how to deal with correctly. :-)
> >My IDE is called vim. :-P *runs and hides*
>
> Better than Emacs loll :-P *also runs and hides*
OK, no need to ignite the flames for that flamewar.
> >You're missing the point. My point was that you can do this with
> >*arbitrarily complex sequences of operations*. Yes search and replace
> >with regex is a specific command that's supported by your IDE, but
> >what about "move one line down, one word over, increment the number
> >by 1 repeated 50 times to repair a table of numbers that had some
> >miscalculations"?
>
> Visual Studio has a "Record Macro" feature, to record keystrokes and
> such, but I haven't used it, so I don't know if it does what you want
> -- but yeah, if it doesn't, I can see why you'd choose
> Vim/Emacs/whatever.
Plus, you've to keep in mind that integration with arbitrary shell
commands add a whole new dimension to this that no Windows-centric IDE
can ever hope to achieve. Like "filter selected lines through grep, sed,
and this 1-line perl script that transforms the text in ways too complex
to express with editor commands". You can even pipe the stuff through an
XML parser and query engine, perform tree-based transformations, etc..
Without an adequately expressive shell on Windows, things like these are
just unattainable wild fancies. For Linux lusers, they're a reality.
This is because the Windows model is to have the app do everything,
handle everything, be everything to the user. If the developers left out
the kitchen sink, you're on your own. The Unix model, by contrast, works
based on the idea that programs should interoperate, the more the
better, so what this program can't do, another can, and the shell
provides the unifying interface for mutual invocation. Thus it lets you
tie together two programs that the developers never dreamed of putting
together, and in that way achieve things they never even conceived when
they wrote their code.
Obligatory quote:
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because
this maximizes the potential for it to be applied to tasks that
are conceptually similar and, more important, to tasks that have
not yet been conceived. -- Michael B. Allen
This also makes for cleaner, more robust programs, because they don't
have to worry about implementing every functionality under the sun: just
do what they were intended to do, and let the user hook them up with
other programs to add functionality on top of it.
It is possible in theory, for example, to have an external program that
parses D code and does queries/transformations on them, and invoke that
from vim on a particular section of code. So you can actually do
IDE-like operations in vim, which in itself has no idea what D code is.
Such is the power of function composition, which the Unix model strives
for.
> >It was just for illustrative purposes. It doesn't have to be "repeat
> >n times"; what about "apply operation X,Y,Z until the end of the
> >enclosing block"?
>
> Uhm, just highlight it and apply the operation to the highlighted
> block...
What I'm getting at is that logical range modifiers for operations are
much more expressive than merely "highlight this, do that". Thing is, in
vim the various movement keys can be applied as modifiers to a
particular action. So instead of going "start highlighting, move 6 lines
down, 13 columns across" you effectively say "lowercase all text from
here till 2 paragraphs down, 5 words across". "Lowercase" is a basic
operation, which is modified by a range specified in terms of logical
units, like paragraphs and words. And because these are logical
entities, not physical positions, the same command can be applied to
vastly different parts of the text and still have the same logical
meaning. That is, 2 paragraphs in this case may span 6 lines, but in
another part of the file it may span 8 lines. By using logical
positioning units, you can have the same command apply to both correctly
without having to tediously construct the physical distance each time.
> >It sucks to have to open 15 different apps and waste time switching
> >between them when I could do everything without my fingers leaving
> >the keyboard for 1 second (and without focus-distracting cycling
> >through windows).
>
> My hands don't leave the keyboard too often either... even the basics
> Alt-Tab/Ctrl-Tab/F8/PageUp/PageDown/etc. get the job done fairly well,
> and the mnemonics (e.g. Alt-O to hit the button with "O" underlined)
> make it 10x better.
Eeek! On most modern keyboards, PgUp/PgDn, etc., are so far out of the
way that you might as well reach for the mouse. Funnily enough, one of
the things I hated the most about vim was its modality. But now in
retrospect, it makes SO much sense. In command mode, all your alphabetic
keys can be put to good use, so your fingers never even leave typewriter
position. The only bad design in vi/vim is the overuse of Esc (which is
slow because of a maldesign in early unix terminal emulation, and also
causes my fingers to twitch for the upper left corner of the keyboard
every now and then). Besides that, everything is lightning fast because
there's no need to reach all the way up to the F1-F12 row of keys, nor
the badly-placed PgUp/PgDn/whatever keys. One can essentially type at
maximum typewriting rate and perform editing commands at that same rate.
It's so efficient that it's addictive. Once you taste that kind of power
you never want to go back to the bad ole world of reaching out for
obscure parts of the keyboard every 4 seconds.
> >Your example went over my head, 'cos I haven't used windows in any
> >serious way for at least 15 years. :-P
>
> lol ok. If you get the chance sometime, might wanna give Windows 7 a
> try. :P
Yikes. I wouldn't touch Windows 7 with a 20-foot sterilized flagpole. XP
was the last usable version of Windows in many senses of the word.
There's a reason the adoption rate of Windows 7 is significantly slower
than MS would like. But I freely admit I'm heavily biased, so take that
with a 1kg grain of salt. :-P
> Last time I used Linux was a few days ago (Ubuntu) so I guess I'd
> naturally have more to say about it haha.
Now don't get me wrong, Ubuntu is doing a very good thing in making
Linux accessible to the masses, but frankly, you haven't _really_ used
Linux until you've mastered the command-line and can regularly compose
long chains of pipes that does magical transformations to data without
thinking twice. In my previous job, there was a part-time contractor who
regularly writes 5-line long bash commands complete with subshells,
multiple redirections, obscure sed/grep tricks, AND HAVE IT ALL WORK THE
FIRST TIME ROUND WITHOUT NEEDING TO HIT BACKSPACE EVEN ONCE. Seriously,
the guy just breathes bash command lines like a fish in water, it's
uncanny. Sometimes you just stare at him compose these incredibly
complex commands and your jaw just drops to the floor in amazement. Your
first thought is "that can't possibly work! Isn't that a typo right
there?! He spelt that option wrong!" and then the next second, your eyes
are popping out of their sockets, "what the... it WORKED?!?!?!".
Sufficiently advanced shell commands are indistinguishible from
physics-defying magic. ;-)
> >Stop right there. Project settings, eh? lol...
>
> Better than configure.in/configure/makefile.in/makefile/all that
> crap. :P
On that, I heartily agree. Autotools is the hellspawn of all evil, next
in line to XML and Javascript. Well, ANYTHING that uses make is,
frankly, the hellspawn of evil just by association. Use SCons. :-)
> >For me, an SConscript does my project management way better than
> >any IDE project settings could ever do.
> >[...]
> >Now try writing an IDE that can do all of _that_ in one go. :-P
>
> I gotta use SCons, haven't used it before :)
Yeah, throw out your makefiles, they're from before the last ice age and
reeks of poor holey design. Use SCons, or any of the much saner modern
incarnations of build tools that aren't dainbramaged. (If you've ever
had to deal with the monstrosities that are makefiles for very large (>2
million lines of code) projects, you'll understand why.)
> >XML is the spawn of evil, next in evilness only to Javascript, but
> >I digress. :-P Seriously though, you could just use xmlstar
> >(google for it) if you really have to. XML is not meant for human
> >consumption. Only machines can process that horribly tedious stuff
> >without its brain turning into a pretzel.
>
> Haha okay well if you claim the entire STACK of tools is evil then I
> guess I can't help you there lol.
OK, I think I went a bit overboard with the hyperbole there. All I
wanteed to say, really, is that XML is designed for machine processing,
not for human processing. Trying to edit XML by hand is like trying to
render a 3D animation with a magnet, a tweezer, and very very steady
hands over the opened casing of your video card's GPU. Trying to read
XML is like trying to give a speech while decrypting your GPG-encoded
notes in your head in real-time. It's just not meant for manual
manipulation. You _want_ to use specialized tools for working with it,
unless you're into masochism.
> >You don't know what you're missing. No, really. Trust me, I know,
> >because I used to hate them too. I hated them so much, that I wrote
> >(well, tried to write) my own editor just so that I didn't have to
> >use them, when pico just didn't cut it anymore for doing serious
> >work. And then my supervisor at my first job made me learn vim.
> >Which made me hate it all the more. Until one day, after investing
> >lots of time (and venting lots of frustration) into learning how to
> >use it properly, it suddenly all *clicked*. Try it sometime. You
> >might find yourself liking what you thought was impossible not to
> >hate, ever. :-)
>
>
> Haha I definitely will. I actually never thought they were /bad/
> (they're just hard to learn and unintuitive, and so I hate them) but I
> definitely agree, I could certainly give them another chance and
> perhaps like them. Will give them another try when I get the chance.
> :)
Well I applaud your willingness to try. :-)
T
--
Lottery: tax on the stupid. -- Slashdotter
