[andybak]

> Sometimes they do exactly what you need, and 70% of the time they're just totally useless.

I thought that but PyCharm scores way better than 70%. I even trust it to do automatic refactors. Sometimes...

> The zippiness on reaction to my typing is another huge deal. If it's anything other than instantaneous, then I notice my editor in a negative light.

Maybe I grew up on IDE's but I type stuff in full only if autocomplete fails me. Maybe I have an appalling memory. Or maybe I'm really slow at typing. Or maybe my variable and method names are too short.

[bpicolo]

I think I'm pretty sensitive to even a minor typing delay. That's not necessarily true for everybody, but it irks me.

> I even trust it to do automatic refactors. Sometimes.

Function extract refactors and the like are definitely within the realm of possibility. Once you want to refactor code across many files it becomes a lot harder in dynamically typed code, for sure.

I guess for a long time I sort of had this view of "ooh I have this awesome expressive language that won't get in my way and I can just power through it all". Don't get me wrong, I totally love python as a language. But I think languages like C# have started to make typing feel like it's more out of your way with type inference, etc.

I mean, this is the sort of code you can write in C# these days (to take a super trivial example):

  var somestuff = someList.Where(x => x.Id > 7)
    .Select(x => x.Name)

Typing in this case is 100% out of your way, but you get all the benefits regardless, and you get all those sort of nice functional-style list operations you expect in other languages.

[Kipters]

More often snippets like this can be even more straightforward:

  var somestuff = from x in someList
                  where x.Id > 7
                  select x.Name

[douche]

Except when you have to wrap it in parentheses and tack a .ToList() onto the end of it, or use something outside the subset that the query syntax supports, it starts looking considerably more ugly than chaining the functions together.

[WorldMaker]

The obvious answer is don't wrap a good query in parentheses, use a second line:

    var somestuff = from x in someList
                    where x.Id > 7
                    select x.Name;

    var somestuffList = somestuff.ToList();

For what it is worth, I personally consider ToList() harmful. I've done a lot of LINQ performance work and the first place I start is with a project-wide search for ToList and start to delete and/or replace calls to ToList to things more appropriate. List is more often than not the wrong data structure for a query result and I've seen too many people use ToList as a debugging crutch without understanding its performance impact.

[camgunz]

They're different ways of programming -- it's where you spend your brain power. You can see codebases that weren't built in IDEs: they generally don't have strong naming conventions in their classes/structures/functions.

One of my hobby projects is in C, and I prefer using an editor to an IDE. Because of an accident of history, public methods tend to be named like `P_PlayerCommandRead`, where `P` means (generally) "physics", and `Player` and `Command` are essentially nested namespaces. I specifically name things this way so that I can type them quickly without spending a lot of brain cycles on figuring out the scopes.

I'm not saying code bases built with IDEs don't have consistent naming, or that code bases built without IDEs have hellish homegrown naming. But it's kind of a "how you grew up" thing, and it latches onto a lot of underlying feelings you have about coding in general.

[btschaegg]

More recently I've come to the conclusion that most of naming must be influenced by "how you grew up". As someone who has mostly touched the Java and Python ecosystems while learning to program, I frequently run into names that seem "weird" to me, because they replace often-used technical words (from those ecosystems) through more obscure synonyms.

C++ also often had that (replacing 'map' through 'transform' and so on) - but since it's a standard, at least it is usually more consistent in its own internal logic. Same goes e.g. for LINQ, which was influenced by SQL instead of LISP-like collection transformation functions.

[pjmlp]

> Same goes e.g. for LINQ, which was influenced by SQL instead of LISP-like collection transformation functions.

This was an explicit decision to make functional programming more palatable to mainstream developers.

Have you read the paper from Erik Meijer?

[btschaegg]

It's pretty obvious that this was a conscious decision. And it makes a lot of sense too, if you think of Microsoft's target audience.

But still - if you're used to the functional "default" naming schema (which mostly comes from math, anyway), it's nontheless something that can be a bit irritating (especially since there's also the "inline SQL syntax" you could use alternatively).

[TeMPOraL]

It definitely is. I started with C++, and at some point I found my way to Common Lisp. At first I was surprised at how many weird names the latter has... and then I got used to them, started to like them, and now I shake my head when I see new languages inventing new names for things that had a perfectly good Lisp name already, probably because they didn't know the concept had already existed for 50+ years...

[douche]

I think part of that is that PyCharm is a JetBrains product. Those guys are the preeminent IDE makers out there at this point. Even Visual Studio is playing catchup to the stuff that they've been offering for years with ReSharper, and Rider is making a compelling case at becoming the best C# editor out there.

I cringe when I have to deal with one big legacy product of ours that still hasn't been converted from a Eclipse project to IntelliJ; it's an order of magnitude more painful to work with.