So this thread ( http://www.gamedev.net/community/forums/topic.asp?topic_id=591040 ) reminded me of one feature I DID like of Visual Studio -- the ability to have it "fold up" code blocks out of the way. That's quite a nice tool to have.

I'm wondering if I can find a similar widget for XEmacs..

And... the answer is yes, I can. Oh yes. "sudo apt-get install cogre semantic cedet-contrib" and turn on a couple of settings and BOSH! I've got code folding and function navigation and all sorts of toys. Yum.

I used micro-emacs long long ago so when Linux came along I used pico because vi is so totally un-emacslike and emacs gosh knows how many of those old hard disks full in size.

Later I'd have to go get pine just so I'd have pico. Just to get control Y and control d and control u! Oh and control a and control e.

Now it is nano and I don't have to go get pine to get it.

But everything is getting so bloated nowadays and disks so big maybe it is getting time to ask myself whether emacs is really so mindbogglingly huge an amount of space to eat up just for an editor.

Come to think of it, I wonder how much space Open Office is eating, and have I ever used it? Hmm, I don't think so.

If that IDE thing being flamed on about is so great how come it hasn't been ported?

<flame on>Can't it handle crosscompiling or autoconf-ing?</flame off>

Oh and control w... can't recall if that matches emacs or not after all these years.

zedz, when I was talking about the digital camera thingy, I was refering about the good/bad old days. There was even a story about a hacker that wrote his own usb webcam so that linux can finally support webcam. yes, times have changed now - even NVIDIA release linux driver now (although it seems to me that the graphics big boys push this - not linux fanboys).

anyway, i think i got enough answer. thank guys & girls.

Quote: Original post by Katie
And... the answer is yes, I can. Oh yes. "sudo apt-get install cogre semantic cedet-contrib" and turn on a couple of settings and BOSH! I've got code folding and function navigation and all sorts of toys. Yum.

Yes, you can.

Some of my former bosses(who were not programmers, of course) would write somewhat like "sumo apt-gat instoll ogre semitic cadet-contra' and all its variations about 50 times until they get it right.

Most people want to use computers without writing "code" or "scripts" of any kind. I think this is a fact, and that Yann L who is way more experienced implied something similar. The need uniform, streamlined, fast and friendly visual tools.

Quote: Original post by Katie
"Some people seriously suggesting to use a vim/emacs and a terminal over a modern IDE."

And yet, bizarrely, UNIX developers manage to be ferociously productive using those environments.

You see, it's not just "emacs and a terminal". It's emacs, scripting languages, macro systems, makefiles that have taken ten years to develop, shell scripting systems that have 20 years of work in them...

Part of the reason is that Vim and emacs are incredibly powerful tools, vim commands are alot faster(once you actually know the commands and don't have to look them up) and also more ergonomical(sic?) for editing text/code than the default VS editor (I've never liked emacs though, pressing a bunch of different control/meta keys at once is just silly)), Allthough VS offers some very important integration with other tools its lack of a command based editor is quite noticable when editing code (When doing more writing than editing its less of an issue). Luckily there is a vi/vim emulation plugin for visual studio so getting the best of both worlds is quite possible.

"Most people want to use computers without writing "code" or "scripts" of any kind."

Hang on. Why are people who want to use computers without writing code trying to compare software development environments?

Quote: Original post by Katie

"Most people want to use computers without writing "code" or "scripts" of any kind."

Hang on. Why are people who want to use computers without writing code trying to compare software development environments?

Because they could be managers to a development team or even corporation but have little to no programming experience themselves?

At least in the places I've been, the technical staff doesn't have free reign over which environments or tools they'll use. Sometimes not even programming methods, if you can believe that. Buzzwords rule.

The "boss"(generally speaking) wants to test the app their staff makes, but he also wants to play solitaire and browse the stocks or latest celeb gossip or telecommute with stockholders or friends in new york. Some of it is necessary, other it's just the being human. We all do that. If he can't get the second effortessly on linux-based OS, why should he have the development boxes and IT department, and subsequently the whole's company desktops switched to non-windows environment? Many use linux for servers, but for desktops, is there an immediate motive clearly visible to non-technical staff?

For a non-negligible sized company, investing on linux and NOT in the most popular OS for desktop apps could be a huge risk. Why should they take it if the reward is 100 miles down the road? Do most managers think like that?

A much more clear distinction should have been kept since way back when between "computer" and "computer inside".

Or "general purpose programmable computer" versus "general purpose appliance-emulator".

Then one could simply point out that the developers need computers, not appliance emulators that happen to have computers buried someplace deep inside.

We did try to use the gamebox or gameconsole versus computer distinction to cover that too for a while but those managers do so like to think of their appliance emulators as computers, and referring to them as gameboxes probably just made them more stubborn instead of helping them see an actual difference.

Discussing tools without context is somewhat futile.

A scalpel is a really fine precision instrument - but it doesn't make gutting fish easier.


Regarding code completion. In some cases developers will work on relatively stable codebase for long periods of time. Code can be cached in brain.

In most typical software shops, the most hardcore developers will spend about one hour over period of entire day mangling source code. The rest will be split between meetings, interruptions, discussions, waiting for builds, configuring stuff, testing, writing reports and other stuff. Code writing will involve a few minute periods. Developers like to dream of The Zone - well, forget it. And with such hands-off relation to code, codebase will change enough to be inconsistent, unintuitive and reading documentation (which doesn't exist) futile - since going through text document is pointless. Just ctrl-space and choose something that looks right. It's good enough.


Debuggers vs. printf. It's not zero sum. As tools and infrastructure mature, trivial problems get increasingly rare. Not only do people no longer need to worry about compiler generating wrong code, crashes are rare or even non-existent.

The general distaste for debugging from hard-core developers comes from finger-pecker programmers - the type of programmer which cannot grasp more than one line at a time. So they open the debugger and roll over 2641 iterations of 5 line binary search since they lack the capacity or will to understand the algorithm itself.

Debuggers also fail in distributed setting. There might be a transient problem with some service, but nobody knows where, why or how. Debugging goes well beyond running a debugger - it may mean some symbol shows in some error log or event log is spammed with obscure Non-paged pool exception, an error which documentation states "Cannot occur".

Troubleshooting is a huge process, where logging and debugger are just two tiny tools. Some developers however do specialize into just parts of the problem and settle just for one.

Quote: Sed. How do windows developers DO anything without sed??? Let alone the lack of a decent grep.

This I agree with. I find it amazing that the search included with even latest Windows is broken by design (it ignores files by extension and similar nonsense). Thankfully, there is at least FIND for emergencies.

At the same time, large portions of Windows resources are opaque or binary, meaning one can only search so deep before running into a brick wall.

Side-effect of this means pure Windows developers just don't dig into problems. They send support ticket to Microsoft and one of their consultants tells that patch will be available in 3 weeks. Managers sign it off and everyone is happy. Client is even billed for extra time and is happy that work will be done that much better since it's taking so long.