[OT] Which IDE / Editor do you use?

[H. S. Teoh]

On Sat, Sep 14, 2013 at 02:54:55AM +0200, Adam D. Ruppe wrote:
> On Friday, 13 September 2013 at 22:29:28 UTC, H. S. Teoh wrote:
> >The only time I've actually had trouble with linux binaries is
> >when there's a problem with libc upgrades
> 
> The biggest offender for my home computer is gtk and glib. libc can
> be painful too - especially with work computers that stick to a
> particular version in the name of stability (I don't blame them,
> updating software is an exercise in pain. Even when they don't
> outright break things, so often they've changed it, now it sucks.).
> 
> But all those glib whatevers really kill me.

You're right. Building GTK apps require 102 dependencies that may or may
not be the exact version the app needs to actually compile. This is
another reason I stay away from GUI apps. They're fat, require a
veritable labyrinth of dependencies that may or may not work, and is
bound to a GUI, generally in an unscriptable way. No thanks. Compiling,
installing, and using a CLI app is far easier and in many cases more
powerful. If I wanted the eye-candy, I'd go to Windows -- they have
better eye-candy.

(Well, I did install Compiz with the 3D rotating cube interface once,
just for some Linux fanboyistic bragging, but ... actually use that for
my everyday tasks? Nah...)


> >On Windows, when installing stuff I used to always get messages like
> >"this installer
> 
> That's not such a problem anymore since Vista. The system does some
> magic rewrites so those naughty programs think they are writing to
> system folders, but are actually pretty isolated.

Ah, figures. My wife's laptop is still running XP. *shrug* It does what
she wants, and I don't see why I should replace it with new expensive
hardware just so I can run Vista (or whatever), for no real added
functionality. But it's good to know they finally got their act
together.


> Still worries me on Linux though! "just run sudo make install", and
> trust you not to do anything wrong? Nope!

I *never* do that. I always tell it to install to a different non-system
$PREFIX. If it can't, I just delete it outright (or, if I desperately
need it, put it inside a chroot).


> On both systems, I don't like installing programs. Whenever I can, I
> like to keep the application in its own folder and run it as my
> limited user account only

Me too.


> (e.g., unzip dmd.zip, run ./dmd2/linux/bin32/dmd. it just worked! and
> any versions can live side by side! and it didn't overwrite anything
> else another program might rely on! WIN!)

+1. :) DMD seriously trumps gcc and its ilk in this area, by a looong
shot. You don't realize what a flimsy fortress of cards gcc can be until
you've tried to install it by hand. It requires 150 different files
installed in 50 scattered locations (along with the 25 requisite
./configure parameters), and if even one of them is wrong, it won't
work.

When the gcc makefile actually works (and it can be a real challenge to
get it to this point, as it's a rather sensitive soul with very high and
demanding standards), it does work like a charm. But when it *doesn't*,
well ... you may not have any hair left after the ordeal, shall we say.

DMD, OTOH, is surprisingly easy to build, and can be run from just about
anywhere. I usually just run it straight from dmd/src.


> >Having said that, though, linux *is* more geared to building from
> >source than anything else
> 
> That'd be great if you didn't have to recreate the original author's
> environment on your computer, or wait seemingly forever for
> ./configure to run, then wait forever again for make to run, just to
> see if the program even does what you want it to do.

Yeah, autotools... that patch upon the patch to a broken bandage over a
festering wound on a patch to a bandage over a primitive system
stretched beyond its simplistic design... OK OK, I'll refrain from
another build system rant here. :-P


> This is why my D programs usually just have a few files you can drop
> in. So I say "get my simpledisplay.d and color.d" and you don't have
> to install it, you don't have to download the same libraries I have,
> you just grab those two files and
> 
> dmd yourapp.d simpledisplay.d color.d
> 
> and boom, it *should* work. While I do have some other libs
> installed, various C headers and so forth, I think it is
> unreasonable to ask you, my user, to have all that too.

Speaking of which, dmd git HEAD appears to have broken terminal.d
sometime recently... if you don't mind could you take a look at it? It's
complaining about some template mismatch or some such. :-(


> If modularity and DRY are at odds, I prefer to err on the side of
> fewer dependencies.

Well, dub is proposed to be a solution to this kind of problems, but I
haven't really felt the need to use it yet. So far, I've been OK with
just downloading D libraries in some local directory and building stuff
from source. But then again, I haven't gotten to the point where my D
code is big enough and complex enough to face these kinds of issues yet,
so who knows. *shrug*


> >but linux's customizability means
> 
> eh to an extent yes, but my custom window manager shouldn't mean
> your notepad program doesn't work. Maybe some special features won't
> be the same, but my preference in one location shouldn't break core
> functionality in another. There is a reasonable common denominator
> here - people don't customize their ELF loaders (much). They don't
> hack their kernels so the syscall numbers don't match. Those things
> actually work, so nobody really cares.
> 
> Why do people use other sound servers/modules or gui libraries?
> Because the default is broken. Not because they disagree, but
> because it is *broken*. So then everyone does their own fixes to
> work around it... and that leads to pain.

Yeah, sound servers have never worked well for me either. I don't even
bother with them nowadays. I usually hate whatever sounds an app makes
anyway, so if sound outright doesn't work, so much the better. As long
as mpg123 / mplayer works, and I can listen to music of my own choice
(instead of whatever dreary soundtrack or cartoon popping sounds the app
author feels I must endure through), and as long as skype can pick up my
voice and transmit the other person's voice, that's good enough.


> So it isn't end user customizability that cause the problem. It is
> mid-user patching a broken core.

I dunno, I find that ALSA works pretty well these days. It has come a
long way since its original inception, when it would mysteriously fail
to work for inscrutable reasons, and then just as mysteriously start
working again upon the next upgrade. Most apps that interface directly
with ALSA tend to Just Work(tm), whereas apps that expect this or that
soundserver to be running generally *don't* work, or don't work very
well.


> >Isn't this thread already [OT]? ;-)
> 
> yeah but it wasn't meant to be a rant thread! oh well.

Hehe... rant threads are fun! As long as people don't take them too
seriously, that is.


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.