Messages

31

General Discussion / Re: uh...hdmi card

« on: August 29, 2013, 11:06:12 pm »

Google is an advertising company.

A rather extreme analogy, but when's the last time you got some spam mail (snail mail) for loan X or gift reward Y and went totally bonkers over it and bought into it?

This is how I see Google, only Google is quite brilliant and makes genuinely awesome contributions to technology ... at the cost of our privacy (because most of what they give us is free). Just remember what you're giving ...

And Chromecast sounds like Google's clever way to know what we're watching (and it's a cool device from what I hear). I won't touch it with a 10 foot poll ... I'd rather go with a competitor (like Roku).

32

General Programming / Re: Let's talk IDEs

« on: August 10, 2013, 07:07:55 pm »

Once you have a file open, it's given a tab like a browser tab. The problem is, once you have too many of those tabs open ... it's equally burdensome to find. I generally try to remember to close tabs when I'm finished when having to use Visual Studio, otherwise it's really annoying.

Right, but I need to find files that aren't open dozens of times a day. I assume this is the case with you too? Do you really have to poke through the entire source tree any time you want to open a new file?

This isn't really a problem in IntelliJ either. I just leave everything open and press Alt+E, which lists recently opened files. You can then type to filter the list and press enter to open it. I hate using the mouse for this kind of stuff, and I'm really happy that I'm provided with efficient ways to circumvent moving my hand those six inches.

There's no way VisualStudio doesn't have something similar to this. It's too obvious a feature.

I think with C++11, the future is very bright. All of <algorithm>, for example, becomes practicably useful with lambda expressions. Although, I have mixed feelings about the new template features (because people use templates to do unusual things that are hard to understand ... so-called template meta-programming).

Templates are always troublesome for Visual Studio to deal with (it almost never finds template definitions). It probably gets worse in C++11.

Sounds really awful. 

It's really not.

And the worst case complexity of hash map is O(n). For a balanced tree, the worst case complexity if O(log n). So if you pick a bad hash function, then a tree theoretically beats your hash map. If your application is performance-sensitive, you really should write your hash function by hand. A default hash function won't generally exploit the structure of your keys.

My impression is that you'd probably not notice a big difference using a TreeMap for casual use ... or if it's only a thousand elements, probably searching an array is substantially faster than either a hash map or a tree map despite having a theoretical complexity of O(n).

Not that any of this matters for casual use of containers ...

Right, but in practice -- even with these generated hash functions -- a HashMap is much more performant than a TreeMap. It's performance-sensitive in that it's nice if it finishes a little faster. The distribution of group sizes is very widely spread for most data sets. Most reducers will have groups with millions of entries in a group, for example.

Most types used as keys are simple compositions of primitives, so it's quite easy to generate a good hash function algorithmically. It follows widely accepted best practices laid out in Effective Java. If you have a field that isn't a primitive, you can just incorporate the value of that object's hashCode into the return value.

These aren't crappy hash functions that are going to result in the O(n) worst case. In fact, I suspect that they're often better than hand-written hash functions because it's so easy to introduce error with this kind of fiddly nonsense.

Fiddly non-sense? You know something about the key space: the distribution and the structure. You're throwing that information away. If you use it, it will almost certainly out-perform a one-size-fits-all solution. The fiddly non-sense is using a generic hash function for everything.

Of course, for casual use, none of this matters ...

operators and inheritance are ugly issues in C++.

Another win for Java (kind of)?

It's not that bad, Ctrl+F7 just compiles that one source file (rather than the whole project). You can't get away with this when writing templated classes and methods though ... and Visual Studio has a lot of trouble with templates so it always gives false alarms (or nothing). You usually have to wait until you can instantiate the class or method to see if it compiles.

I'm sure I'd learn how to function quite well without red squigglies, but I'm quite confident that it saves me many minutes a day by informing me of an error or oversight as soon as it becomes an issue rather than further down the line. You just can't get the same level of granularity if you have to manually kick off the compiler any time you want to check for errors.

This isn't the only advantage to red squigglies, though. Since the java compiler gives more information than just the line number, the IDE can highlight just the problem area, which often helps make the underlying problem a little more obvious.

I'm sure Visual Studio can do some of what you described. I just don't know how to use it well enough to do those tricks.

Regarding return types, in C++11, now you can do something like this (which I have mixed feelings about):

Code: [Select]

auto clThing = clOtherThing.DoSomething(); // Return type inferred automatically

clThing.DoSomething();

EDIT: Small English corrections.

Yuck. That seems like it'd throw many advantages that strong types provide out of the window. I'd much rather rely on my IDE to auto-infer the return type.

Code: [Select]

Thing thing1 = new Thing(new Stuff(1));
Thing thing2 = new Thing(new Stuff(1));

Would yield:

Code: [Select]

Stuff stuff = new Stuff(1);
Thing thing1 = new Thing(stuff);
Thing thing2 = new Thing(stuff);

I don't see much advantage in this "feature", do you? It seems something one would use purely out of laziness, but that's a problem the IDE should be able to take care of without throwing away all of the nice advantages type safety brings.

If the type of a variable is wrong, the IDE should be able to correct it for you. This comes up a lot, now that I think about it. I just cursor over the line with the error, press Alt-Enter, and there's an option to change the type of the variable. Same goes for return types of methods, parameters, etc.

The type is not lost at all. The compiler can infer the type from the return type of DoSomething(). C++11 is still a strongly typed language, it just makes more effective use of the compile-time type information.

33

General Programming / Re: Let's talk IDEs

« on: August 10, 2013, 03:55:20 pm »

In Visual Studio, you spend time looking at a long list of files in the Solution Explorer. This is made less worse by grouping the long list of sources into subgroups. Although, seeing that we have so many constituent projects, it's already time consuming to scroll through the list of projects, expand the tree and then further find the source you want! Shell is more efficient here, especially when you know the source tree by heart. Of course, if you had a text filter like you claim IntelliJ has, that would help (although file finding in VS or Windows is slower than Unix find!).

That's completely ridiculous! I'd never navigate that way. I press Ctrl+Shift+N and type the name of the class/file I want and press Enter. There's no delay... the index makes it functionally instantaneous. Much, much faster than clicking through the source tree... does visual studio really not do that?

Once you have a file open, it's given a tab like a browser tab. The problem is, once you have too many of those tabs open ... it's equally burdensome to find. I generally try to remember to close tabs when I'm finished when having to use Visual Studio, otherwise it's really annoying.

And the Unix shell is definitely more efficient than Visual Studio ... by an enormous margin. There's no random freeze-ups, there's no reloading hundreds of projects when you regenerate a solution with CMake, there's no inability to find template definitions, there's no long monolithic list of sources to painstakingly scroll through, there's no 15 minute link time, there's no /MP glitches, there's no false positive red squiggly lines, there's no 10GB metadata files (which matters when you have terabytes of medical images on your drive) ...

But the biggest time wasters in Visual Studio are random freeze-ups and reloading project files. And it performs this way even on a modern OS like Windows Server 2008 on modern hardware (24 cores, 72GB of RAM).

These aren't problems in a Java development environment. This is all the more reason for me to steer clear of C++. I'll actually actively avoid companies that use C++ after hearing about all this nonsense. It sounds absolutely infuriating. I've worked with and been frustrated by small C++ projects; I guess I should've figured those issues would only compound as the codebase gets more complex.

I think with C++11, the future is very bright. All of <algorithm>, for example, becomes practicably useful with lambda expressions. Although, I have mixed feelings about the new template features (because people use templates to do unusual things that are hard to understand ... so-called template meta-programming).

Templates are always troublesome for Visual Studio to deal with (it almost never finds template definitions). It probably gets worse in C++11.

Then it seems you don't use a hash map for anything performant in the first place.

Uh... what? The generated hash function is good enough that it's still O(1) average time (instead of O(log n)). It's still much faster than a TreeMap, especially when the overhead is compounded by many terabytes of data (in groups of up to a few 1000).

And the worst case complexity of hash map is O(n). For a balanced tree, the worst case complexity if O(log n). So if you pick a bad hash function, then a tree theoretically beats your hash map. If your application is performance-sensitive, you really should write your hash function by hand. A default hash function won't generally exploit the structure of your keys.

My impression is that you'd probably not notice a big difference using a TreeMap for casual use ... or if it's only a thousand elements, probably searching an array is substantially faster than either a hash map or a tree map despite having a theoretical complexity of O(n).

Not that any of this matters for casual use of containers ...

Using HashMap along with the auto-generated hashCode provides enough speed improvement to justify using it over TreeMap and implementing compareTo.

As an aside: since every type in the java libraries that you could reasonably expect to implement a reliable hash function does, it's actually a lot easier to design a performant hash funciton in the majority of cases than you'd think.

That's completely overkill. Nice as it may be that your IDE can fill in some code for you, I'd have do the reverse of implementing operator==: Erase most of that. This is all I'd want:

Code: [Select]

bool operator==(const Thing &clOther) const {
  if (this == &clOther)
    return true;
  // TODO: Fill this in.
  return false;
}
That's not nearly as annoying or time consuming to write as you claim it to be, albeit less convenient than having it already. No living templates needed here.

You're only accepting Thing. In Java, equals must accept an arbitrary Object, so to have a completely general equals, it has to consider the type. If you only expect to receive instances of the same object, there's an option for that in the generation window.

operators and inheritance are ugly issues in C++.

In addition, there's no dereferencing in Java. If you want to verify that member variables are equal, you have to do it in the verbose way that the IDE used.

I'm sure you'll think of a convincing example. Just remember I'm not trying to convince you to use a non-IDE environment.

But I'm still convinced that a lot of the text-related functionality you listed can already be done with vim or emacs. And kind of cheating, plug clang into vim (since clang is modular and exposes its parser API), and you could pretty much do anything text-related you listed in vim with C or C++ ... actually on that thought, I just found this:
http://www.vim.org/scripts/script.php?script_id=3302

That apparently even does red squiggly lines ...

I still think it's cheating in the sense that vim is given more context than a normal text editor.

Will I use it in vim? Probably not ...

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

Or just check to see if it compiles every so often ... you should do that any way, red lines or not. Of course, if you're stupid enough to write 1000 lines without checking if it compiles (even with red lines), you deserve what you get.

Right, but that's annoying and inefficient. That's exactly my point. I'm happy to agree that if you don't have reliable red squigglies, you should be manually checking if things compile. However, it's far less annoying to have that information as you type. I almost never have false positives for reasons that wouldn't be present using the build file anyway (need to resolve dependencies, pull changes, etc.)

It's not that bad, Ctrl+F7 just compiles that one source file (rather than the whole project). You can't get away with this when writing templated classes and methods though ... and Visual Studio has a lot of trouble with templates so it always gives false alarms (or nothing). You usually have to wait until you can instantiate the class or method to see if it compiles.

That's very handy. I could definitely benefit from something like that.

All of the features I listed are, I think. They save a lot of time.

It's not like the IDE does much thinking for you. It just saves you the trouble typing when you know exactly what you want. That's what an IDE should do, I think.

Another handy one: if you want to pull the return value of some method call out into a variable because you've discovered you want to use it in another place, you just put the cursor over it, press Ctrl+Alt+V and type a name for the variable. It also detects places that you've made exactly the same method call and replaces it with the variable.

I'm sure Visual Studio can do some of what you described. I just don't know how to use it well enough to do those tricks.

Regarding return types, in C++11, now you can do something like this (which I have mixed feelings about):

Code: [Select]

auto clThing = clOtherThing.DoSomething(); // Return type inferred automatically

clThing.DoSomething();

EDIT: Small English corrections.

34

General Programming / Re: Let's talk IDEs

« on: August 10, 2013, 12:12:55 pm »

We have a convention for how sources are organized in the tree. I normally know exactly where to look just from the functionality I need.

I normally need to find some text or function definition in one of those files rather than a file itself ...

Right. I'm sure you know where stuff is. I think what I'm meaning to ask is when you know exactly what file you want to open or definition you want to go to, how do you do it? Do you use visual studio?

In Visual Studio, you spend time looking at a long list of files in the Solution Explorer. This is made less worse by grouping the long list of sources into subgroups. Although, seeing that we have so many constituent projects, it's already time consuming to scroll through the list of projects, expand the tree and then further find the source you want! Shell is more efficient here, especially when you know the source tree by heart. Of course, if you had a text filter like you claim IntelliJ has, that would help (although file finding in VS or Windows is slower than Unix find!).

I'm not trying to convince you to use a non-IDE environment. I was only arguing that a Unix shell environment is more efficient for development than an IDE. We've established that Visual Studio is the culprit of my findings (which I thought was the gold standard for IDEs).

Well, if a unix shell is actually more efficient for development than an IDE, I'd like to be convinced. So far, I'm not even close.

And the Unix shell is definitely more efficient than Visual Studio ... by an enormous margin. There's no random freeze-ups, there's no reloading hundreds of projects when you regenerate a solution with CMake, there's no inability to find template definitions, there's no long monolithic list of sources to painstakingly scroll through, there's no 15 minute link time, there's no /MP glitches, there's no false positive red squiggly lines, there's no 10GB metadata files (which matters when you have terabytes of medical images on your drive) ...

But the biggest time wasters in Visual Studio are random freeze-ups and reloading project files. And it performs this way even on a modern OS like Windows Server 2008 on modern hardware (24 cores, 72GB of RAM).

I don't normally have to write hash functions. If I didn't care about performance, I'd just use std::map and write a less than operator. If I cared about performance, I would try to derive a hash function myself that wouldn't likely collide and plug it into std::unordered_map.

Although, some code templates could be useful. Nifty.

I don't think caring about performance is binary. I usually care enough about performance to use HashMap over TreeMap, but I rarely see much worth in optimizing the hash function.

Then it seems you don't use a hash map for anything performant in the first place.

Anyway, the equals it generates is generally about as performant as you can hope for, and it'd still be a little annoying to write:

Code: [Select]

  @Override
  public boolean equals(Object o) {
    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }

    TimeSegment that = (TimeSegment)o;

    if (count != that.count) {
      return false;
    }
    if (unit != that.unit) {
      return false;
    }

    return true;
  }

That's completely overkill. Nice as it may be that your IDE can fill in some code for you, I'd have do the reverse of implementing operator==: Erase most of that. This is all I'd want:

Code: [Select]

bool operator==(const Thing &clOther) const {
  if (this == &clOther)
    return true;
  // TODO: Fill this in.
  return false;
}
That's not nearly as annoying or time consuming to write as you claim it to be, albeit less convenient than having it already. No living templates needed here.

I'm sure you'll think of a convincing example. Just remember I'm not trying to convince you to use a non-IDE environment.

But I'm still convinced that a lot of the text-related functionality you listed can already be done with vim or emacs. And kind of cheating, plug clang into vim (since clang is modular and exposes its parser API), and you could pretty much do anything text-related you listed in vim with C or C++ ... actually on that thought, I just found this:
http://www.vim.org/scripts/script.php?script_id=3302

That apparently even does red squiggly lines ...

I still think it's cheating in the sense that vim is given more context than a normal text editor.

Will I use it in vim? Probably not ...

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

Or just check to see if it compiles every so often ... you should do that any way, red lines or not. Of course, if you're stupid enough to write 1000 lines without checking if it compiles (even with red lines), you deserve what you get.

I'd really love to see a development environment that implemented half of the features I listed in any significant capacity. This isn't something you can accomplish by shelling out to the compiler. I'll try to demonstrate.

Let's say I have a Map with String keys and Integer values. If it's the only iterable in scope, this is what I see when I type "iter<tab>":



If I update it to map.entrySet(), this is what I see:



notice that the type is updated automatically. This is really the beauty of these live templates. You see what the code the IDE is generating for you as you update the input. When I press "enter", I'm prompted to enter a name for the iteration variable. The generated name is usually acceptable (although not in this case).


Let's say I have a final member variable that isn't initialized. I can press <Alt>-<Enter> over it and I get this menu:



In this case, the first option is what I want. If I press <Enter>, I get this:



Now let's say I want to delegate the methods that Map declares to the member variable. I can do that by pressing <Alt>-N, typing "del" and pressing <Enter>:



I get this menu, which is a little more useful when there's more than one option:



Then it shows me a list of methods that I could delegate. Let's say I want to delegate everything except for get(Object). There's probably some fancy way to do this with the keyboard, but I'd probably just do <Ctrl>-A to select them all and then delete get, or just Ctrl-Click get:



This is what I get:



Notice this feature is only possible if the editor is aware of what methods Map implements. It'll be able to do this even if the delegate isn't typed as a Map. It just has to be anything that implements Map. The editor is able to infer all of that. It took less than 10 seconds to generate all of that code. You can imagine it'd take a long time to type it manually in the general case, especially if the interface you're writing a delegate for has lots of methods.

That's very handy. I could definitely benefit from something like that.

35

General Programming / Re: Let's talk IDEs

« on: August 05, 2013, 02:40:16 am »

The problem is that Visual Studio does not handle template definitions very well (at all!). When using extraordinarily large code bases like ours, it often doesn't have an answer in the first place.

Out of curiosity, how many lines of code are you talking about? I'm talking about projects that I have a reasonable probability of needing access to on a daily basis.

I've never counted the lines of code, but it's a large machine learning and computer vision codebase used to build the tools used worldwide in hospitals (quite literally, not exaggerated) ... I don't know what else I could possibly tell you without divulging too much information other than to give you the impression of a mature decade-old code base used to solve a variety of medical imaging problems.

(3) and (4) are very time consuming. That and occasional and mysterious VS freeze-ups.

I probably use these more than most features available. It'd be a huge pain in the ass to develop without them... if you know exactly what a file is named, how do you find it?

We have a convention for how sources are organized in the tree. I normally know exactly where to look just from the functionality I need.

I normally need to find some text or function definition in one of those files rather than a file itself ...

But isn't it interesting that almost everything you've listed has everything to do with text editing and little to do with programming. Granted an IDE is a glorified text editor that can parse a language and communicate with a compiler. Using a powerful text editor like vim or emacs could already do 1, 2, 4, 5, 8, and 9 and probably do it faster and better due to the pure use of a keyboard.

They're not, though. The majority of the examples I listed require that the IDE be capable of inferring things only possible if it does some pretty deep language-level analysis. These aren't things you could easily implement with a vim plugin. (And for the record, I almost never use the mouse while programming. That's actually why I listed the keyboard shortcuts for the examples I gave. If I missed any, it was only out of laziness.)

For example, code templates aren't usually just macros. I guess IntelliJ likes to call them "live templates". The one I use most often is "iter<tab>". It generates this code:

Code: [Select]

for (<Type> <inferred variable name> : <...> ) {
}

It puts your cursor where "..." is. As you update it, a context / locality sensitive dropdown menu appears as you type, of course. More importantly, it also updates the type and name of the variable.

The implement/delegate methods are similarly not just keyboard-triggered text barf. It requires that the editor be aware of fancy language-level analysis that would be a marvelous pain in the ass to implement as effectively in a vim plugin.

If you can show me a "non-IDE" environment that has features like the ones I'm listing, please show me. Perhaps I'm not doing these features justice, but they would not be easy to implement. And why would I want to do that when IntelliJ does them so well already?

I'm not trying to convince you to use a non-IDE environment. I was only arguing that a Unix shell environment is more efficient for development than an IDE. We've established that Visual Studio is the culprit of my findings (which I thought was the gold standard for IDEs).

Another I forgot: generate equals/hashCode. In most cases, a very formulaic implementation is all you want. The IDE does it for you:

Code: [Select]

@Override
  public int hashCode() {
    int result = (int)(count ^ (count >>> 32));
    result = 31 * result + (unit != null ? unit.hashCode() : 0);
    return result;
  }

I don't normally have to write hash functions. If I didn't care about performance, I'd just use std::map and write a less than operator. If I cared about performance, I would try to derive a hash function myself that wouldn't likely collide and plug it into std::unordered_map.

Although, some code templates could be useful. Nifty.

Couple this with command line tools and you have a complete development environment. Use Clang over GCC and you have point 7 leaving point 6, definition/declaration lookups and debugging as the only unique conveniences from an IDE.

Like I mentioned up there, I don't think I did the features justice. They're not something you could implement reliably without doing pretty complicated analysis of the codebase you're working with. And when you're working with a large codebase, the only way these things could function responsively is if there's a project-wide (multi-module) in-memory index.

I'm sure you'll think of a convincing example. Just remember I'm not trying to convince you to use a non-IDE environment.

So would you really think it is goofy to use the Unix shell environment on a large code base over those three conveniences? Indeed, looking up definitions and declarations are useful if you're new to a code base, but if you're already very familiar, you almost never need that anyway. Oh sure, if you call some uncommon function, then maybe it's nice to have at that moment ...

I think you're not giving the things I've listed enough credit. Each one saves me between 5 seconds and 2 minutes with each use, depending on the instance. For emphasis: I really don't think that these features are as readily replicated with command line tools as you seem to be suggesting. Fundamentally, I think an IDE should minimize the amount of time you spend programming where your typing speed is the bottleneck. Before becoming proficient with IntelliJ, it happened pretty often that I knew exactly what I wanted to type, but I'd have to spend several minutes minutes typing it. That doesn't happen nearly as often now.

Like I said, please show me a vim environment that works as well and I'd actually give serious consideration into using it.

But from what you've described, VS really does suck and IntelliJ is nice.

I haven't used VS on a big codebase before. I used it for some personal C# projects a while ago and it seemed nice, but I'll be happy to take your word that it sucks. IntelliJ is pretty fuckin' awesome.

I know it's hard to enumerate ideas on the spot ... I'm sure you'll expand upon this list.

It is, but I'm quite convinced that most of the items on the list I provided could not be implemented in a reliable and performant way using command line tools. When it comes down to it, the best thing is that I can do all of this stuff out of the box. I don't have to collect dozens of plugins and scripts just to get an environment that might work well enough that I don't spend every moment I'm programming missing IntelliJ

But I'm still convinced that a lot of the text-related functionality you listed can already be done with vim or emacs. And kind of cheating, plug clang into vim (since clang is modular and exposes its parser API), and you could pretty much do anything text-related you listed in vim with C or C++ ... actually on that thought, I just found this:
http://www.vim.org/scripts/script.php?script_id=3302

That apparently even does red squiggly lines ...

I still think it's cheating in the sense that vim is given more context than a normal text editor.

Will I use it in vim? Probably not ...

36

General Programming / Re: Let's talk IDEs

« on: August 04, 2013, 10:44:21 pm »

I can grep for useages/definitions, but I'd much rather press a button and instantly have an answer, wouldn't you? Maybe VS sucks, but IntellJ doesn't have any of the problems you're listing.

The problem is that Visual Studio does not handle template definitions very well (at all!). When using extraordinarily large code bases like ours, it often doesn't have an answer in the first place.

That's not a problem with IntelliJ. Go to definition is effectively instantaneous (probably on the order of 10s of milliseconds). Same with find useages, find implements, and so on. I have a reasonably beefy laptop (16GB RAM), so I give IntelliJ a max heap size of 4GB. It keeps an in-memory index (I think it's lazy-loaded from disk) of definitions, files, useages, etc. I'd imagine I have that to thank for its responsiveness.

Just for good measure, here are more reasons I love using an IDE:

• Generate getters/setters for fields can be done with a few keystrokes. (Alt+N -> type "get" -> Enter -> Select fields -> Enter)
• Code templates are fuckin' amazing. If I want to loop over a structure, I type "iter<tab>", type the name of the variable, and press enter. All of the type information is inferred. These code templates exist for quite a few things. "public static void main(String[] args) { ... }" is "psvm<tab>"
• Searching for files is super easy. Alt+Shift+N, type the name of the file. You can also use camel case so if you want to search for "ReallyReallyRidiculouslyLongClassName", you can just type "RRRL"
• Swapping between recently used files is really an awesome thing, I've found. Alt+E, Enter to go to last recent file. Alt+E brings up a list of the last ~20 open files, and you can type to filter the list.
• Added a constructor parameter? Cursor over it, press Alt+Enter, "bind", Enter to generate a field and assign the variable to the field in the constructor.
• Squiggly red lines to indicate compile errors. I assume you have something like this with whatever you use, but it'd be such a ridiculous pain in the ass to work without them.
• When there's an error, Alt+Enter brings up a context-aware list of possible fixes for it. For example, if something needs a typecast, it'll generate it for you. If you're not handling an error that some method call throws, you can choose to wrap it in try/catch or add it to the method signature.
• Automatically generate implement/override method stubs (Alt+N, "Ov" or "imp", Enter, choose methods to override, Enter)
• Writing a decorator? When you have member that implements/extends the same interface/class that the class you're working in does, you can automatically generate delegate methods for all of them. (Alt+N, "Del", select member to delegate to, select methods to delegate, Enter)

These are just off the top of my head, of course. I should start keeping a list.

Here are my complaints for your lists:

• OK ...
• OK ...
• But this file and text search feature in Visual Studio is dreadfully slow (find is much faster). It takes minutes for it to find a file or text in a file.
• Visual Studio has tabs for opened buffers. Nice until you have like 20 of them, then it's time consuming to find the file you want to edit. Switching buffers in vim is faster. You can type in a filter, so you don't have this problem.
• OK ...
• Yes, squiggly red lines are nice ... when they don't give false alarms (and they give false alarms a lot in VS).
• I don't think VS has that feature.
• OK ...
• OK ...

(3) and (4) are very time consuming. That and occasional and mysterious VS freeze-ups.

But isn't it interesting that almost everything you've listed has everything to do with text editing and little to do with programming. Granted an IDE is a glorified text editor that can parse a language and communicate with a compiler. Using a powerful text editor like vim or emacs could already do 1, 2, 4, 5, 8, and 9 and probably do it faster and better due to the pure use of a keyboard. Couple this with command line tools and you have a complete development environment. Use Clang over GCC and you have point 7 leaving point 6, definition/declaration lookups and debugging as the only unique conveniences from an IDE.

So would you really think it is goofy to use the Unix shell environment on a large code base over those three conveniences? Indeed, looking up definitions and declarations are useful if you're new to a code base, but if you're already very familiar, you almost never need that anyway. Oh sure, if you call some uncommon function, then maybe it's nice to have at that moment ...

But from what you've described, VS really does suck and IntelliJ is nice.

I know it's hard to enumerate ideas on the spot ... I'm sure you'll expand upon this list.

37

General Programming / Re: Let's talk IDEs

« on: August 04, 2013, 02:04:27 pm »

While what you say seems reasonable, I have experience both development environments on a large code base and I disagree here. I observe that an IDE is very helpful if you're unfamiliar with the code base. However, once you're very familiar, you really would be more productive with a Unix shell environment for everything except possibly debugging. Although, from my personal experience, the bugs that stump me are often not easy to work out in a debugger (e.g. the crash occurs several days later, it's a multi-threaded bug, or it's impossibly slow in debug mode).

Me too, and I still think it's pretty goofy to not use an IDE.

While I agree that it gets easier as you become more familiar with a codebase, navigation is still significantly more clumsy without a good IDE. It also makes it easier to keep up with a constantly changing codebase.

Navigation is already clumsy with an IDE like Visual Studio ... Maybe not for your IDE.

Yes, a debugger doesn't help a ton in those situations, but that's not really relevant, right? We're talking about tools that improve efficiency, not enable developers to write perfect code.

I told you my experience ... they're great if you don't know the code base and that's really about it. The ones I use (all Visual Studio) all have annoying quirks and waste tons of time.

Where do you see improvement in efficiency for your task?

But this should come as no surprise as big code bases like FreeBSD and Linux are very likely exclusively developed with vim and emacs ...

I don't think I've made the claim that it's impossible, just that it's probably unreasonable. These projects are developed mostly by relative dinosaurs who are probably pretty resistant to using IDEs because they've already invested time in learning how to use an environment that works well for them.

You're right, you haven't made this claim. But a lot of developers on the FreeBSD team, for example, are not dinosaurs.

I think that the fact that the average person contributing to the Linux kernel probably doesn't use an IDE (I'm taking your word on that, by the way) is more an artifact of it being the status quo and less so that it's actually a better solution. We might say the same about the quality of the tools available for C, for that matter. (As an aside, I think I'd rather be a goat farmer than develop C/C++ fulltime.)

You're right, I made an empty claim. I'm guessing that most, if not all, kernel developers for either the FreeBSD or Linux do not use an IDE just from the observation that both systems are built with make(1). Besides, there are no project files to open the source tree in any IDE unless an IDE could read Makefiles.

But maybe an IDE really doesn't help with development as much as claimed ... this has been my experience.

In the end, I think quirks in the IDE (UI and otherwise) waste unimaginable amounts of time. For example, regenerating a VS 2010 solution from CMake, while VS 2010 is running, causes all sorts of havoc. Having to reload hundreds of projects is much slower than just Task Manager -> Kill devenv -> Start devenv again. This kind of crap man ... it's a big time waster. Not really the IDE's fault, but it takes VS 2010 15 minutes to link one of the executables ... the same code takes just 1-2 minutes to link with gcc. I despise Visual Studio 2010 with a passion (2008 isn't so stupid).

Honestly, I have very little experience with windows IDEs. These kinds of things never bother me in a Java environment.

Lucky you. I have very little experience with IDEs other than Visual Studio.

UI quirks in the windowing environment are also huge time wasters. We're just now transitioning to the superior Windows 7, but Windows XP has so many very annoying and time consuming quirks. I feel like 10% of the day is spent waiting for Windows or Visual Studio to do something or working around some quirk ...

The only kinds of things like this that come up for me are more the fault of my desktop environment than the IDE itself. I'm just too lazy to switch off of unity.

Maybe if you wanted a birds eye view of a folder of images ... these tools do nothing for you.  It's really hard to imagine scenarios where you would be wasting any time using these tools.  You would have to write a program or script to accomplish tasks those simple/ancient tools can do for you.

Right, but that was kind of my point, wasn't it? When it's more convenient to use unix tools, then fuckin' use unix tools. But I think it's silly to latch to them and pretend that they're the best solution for every situation.

Yes, and I hate to sound religious, but they've demonstrated themselves to be the best development tools so far.

Please tell me, where does an IDE help you? I could probably enumerate a list of where, for example, Visual Studio wastes a lot my time. Gosh, nothing like waiting for Visual Studio to "Go to definition" on a template only to have it tell you several minutes later that it couldn't find it. But grep? Grep works!

Maybe your IDE is more responsive and less quirky. It sounds like you're using a Linux development station too.

38

General Programming / Re: Let's talk IDEs

« on: August 03, 2013, 12:10:49 pm »

Right, but it's not like you have to pick one. That's kind of my point, actually. Use the right tool for the job. It's completely asinine to not use an IDE if you're working with a large codebase, and it's also pretty stupid to not take advantage of commandline tools where appropriate.

While what you say seems reasonable, I have experience both development environments on a large code base and I disagree here. I observe that an IDE is very helpful if you're unfamiliar with the code base. However, once you're very familiar, you really would be more productive with a Unix shell environment for everything except possibly debugging. Although, from my personal experience, the bugs that stump me are often not easy to work out in a debugger (e.g. the crash occurs several days later, it's a multi-threaded bug, or it's impossibly slow in debug mode).

But this should come as no surprise as big code bases like FreeBSD and Linux are very likely exclusively developed with vim and emacs ...

In the end, I think quirks in the IDE (UI and otherwise) waste unimaginable amounts of time. For example, regenerating a VS 2010 solution from CMake, while VS 2010 is running, causes all sorts of havoc. Having to reload hundreds of projects is much slower than just Task Manager -> Kill devenv -> Start devenv again. This kind of crap man ... it's a big time waster. Not really the IDE's fault, but it takes VS 2010 15 minutes to link one of the executables ... the same code takes just 1-2 minutes to link with gcc. I despise Visual Studio 2010 with a passion (2008 isn't so stupid).

UI quirks in the windowing environment are also huge time wasters. We're just now transitioning to the superior Windows 7, but Windows XP has so many very annoying and time consuming quirks. I feel like 10% of the day is spent waiting for Windows or Visual Studio to do something or working around some quirk ...

The ancient tools you've mentioned are certainly more efficient for some things. I'd lose a significant chunk of time if I had to commit to using them exclusively, though.

Maybe if you wanted a birds eye view of a folder of images ... these tools do nothing for you.  It's really hard to imagine scenarios where you would be wasting any time using these tools.  You would have to write a program or script to accomplish tasks those simple/ancient tools can do for you.

39

General Programming / Re: Let's talk IDEs

« on: August 02, 2013, 10:32:36 pm »

The thing is, there are IDE plugins that replicate 95% of the needed functionality in vim. I use IdeaVim for IntelliJ.

Yes, you can navigate around a couple of files with great speed and efficiency using only vim, but that's not where the most significant benefit in using an IDE comes from.

There are certain functionalities that IDEs have that stuff like vim just can't have without either (usually both):
a) an obscene amount of overhead involved with setup.
b) clunky, difficult-to-use interfaces.

Here are a few decent examples that illustrate this:

Let's say I'm using only vim while working in a codebase that's spanned by dozens of projects and there's an interface in a project that's upstream of everything else. How would I go about finding all implementations of that interface? In IntelliJ, I put my cursor over the interface and press Ctrl+Shift+7, and BAM. There's a list.

What if I'm missing an import and I didn't feel like thinking about which package LoggerFactory comes from. In IntelliJ, unambiguous imports are automatically added.

What if I want to move a package into a different parent? Click and drag. That's it. No fixing the package declarations or imports. It's all done for me.

Don't even get me started about the interactive debugger that magically interfaces with code external to the project you're working in (i.e., you can add it as a module and add breakpoints in the foreign code).

I'm sure the guy you worked with managed to be very productive just using vim, but I guarantee you he spent a lot of time doing things that an IDE could've take care of for him.

There are few IDEs that can effectively replicate 95% of the functionality of a proper Unix shell.

I swear, I'm appalled that simple and ancient tools like grep, sed, awk, vim, find, sh are still more efficient and effective than modern tools like Windows Explorer and Visual Studio ... granted Visual Studio debugging is nicer than everything else (but gcc is faster at compiling than the pile of crap that VS 2010 is without generating 10GB of compiler metadata).

40

General Discussion / Re: Let's update!

« on: July 27, 2013, 01:45:41 pm »

What do you do?

It's certainly unusual work. We research, develop and productize algorithms for use in medical image analysis. The tasks are certainly not trivial and we primarily focus on automatic segmentation of structures in the body in several modalities and employ a mixture of machine learning and computer vision approaches. It's really cool that brand spanking new algorithms end up in practical use very quickly (rather than rotting in journals for years).

Here's our problem: Our team is comprised purely of scientists, all of which are currently expected to research, develop, maintain, document, productize, test, and follow delivery procedures for a variety of customers. We have trouble maintaining a balance between the software engineering/architecture aspect, and the research aspect due to tight deadlines. It would be helpful to have a software engineer who could focus on the software side of the development, and that would include, for example:

• Deliveries (e.g. TFS, ClearCase, Productization, Testing)
• Helping to maintain our code base.
• Developing new interfaces and tools in the code base.
• Improving existing interfaces.
• Helping us document existing interfaces.
• Quality control (e.g. maintaining review information, source analysis, etc...)

EDIT: We work primarily with C++, Visual Studio, CMake, and Subversion. The code base is computer vision and machine learning oriented and some of it is mathematically involved (so some numerical analysis could be helpful).

41

General Discussion / Re: Let's update!

« on: July 26, 2013, 12:15:55 pm »

Scheduled my 2nd phone interview for tomorrow for a programming position at CHOP.  Hope it goes well, as I really want to work there.

We're looking for software engineers, so if anyone is interested, send your CV by PM.

42

General Discussion / Re: Let's hear it!

« on: July 01, 2013, 02:52:15 pm »

Wow, people are still here?

Greetings.

Of course! I imagine 20-30 persistent members check this forum almost daily despite the lack of activity.

The forum is a habit.

43

[x86] Announcements / Re: 2013 meetup!?

« on: June 10, 2013, 06:48:40 pm »

I'll be in Asilomar, CA from June 28th to July 3rd for IPMI 2013.

I don't know how much free time I'll have (and it's a bit far from San Fransisco ... 100 miles).

44

Botdev / Re: Creating BNX clone for IRC

« on: May 26, 2013, 01:26:58 pm »

I've added a seen and lastseen command just yesterday. Normally, IRC supports WHOWAS, but it apparently can be disabled by the server (e.g. freenode). seen merely tells you if the bot has seen someone, when and in which channel the user was last seen. The seen list is updated on join and privmsg (to a channel). A timer writes the updated seen list to file once every 5 minutes. lastseen tells you who has been seen in a channel in the past day.

I'll try to address the daemonization problem today. It would be nice to be able to daemonize the bot on both Windows (without being a service) and on UNIX-like systems.

I'll try to release 1.2 in early June.

45

Gaming / Re: Diablo 3

« on: May 04, 2013, 09:04:30 pm »

Anyone else annoyed by the gem system?

http://www.diablowiki.net/Gem

Some of these are unattainable unless you have no life.