Recommended IDE...?

Joel Bernstein joel at
Fri Jan 17 16:56:19 GMT 2014

I don't feel like this was in any way a reply to what I asked. You seem to
be trying to pick holes in the idea of "integration" as a differentiator
between a programmer's editor and an IDE. This seems at best to be missing
the point. I already mentioned, for example, integration with testing,
version control, issue trackers, and made clear that I meant this on a
workflow rather than merely per-file basis. Can you ask a better question?
Or perhaps you did, but it got lost in the ranting?


On 17 January 2014 17:27, Kent Fredric <kentfredric at> wrote:

> On 17 January 2014 23:36, Joel Bernstein <joel at> wrote:
> > But vim isn't an IDE, at least not as I understand one. Isn't there a
> > distinction to be made between "IDE" and "programmable text editor", in
> > terms of the "integration"? I've heard people assert that dynamic
> languages
> > don't mix with IDEs but AFAIK most IDE features come from the Smalltalk
> > browser, and Smalltalk is of course an incredibly dynamic language in
> terms
> > of typing and dispatch.
> >
> I'm curious what the definition of "Integrated" means in this context.
> - Vim supports embedded Perl execution
> - Vim extensions support running perl code from vim
> - Vim extensions support running tests from vim
> - Vim extensions do provide some kinds of method completion, albeit limited
> and execute in a rather global scope.
> I don't use most of those features, but I guess what I'm saying is, when
> you say "IDE", what features are you expecting as a result?
> Many the features you require are available as vim extensions, and many of
> the features you expect of languages like Java are mostly unsupportable in
> many IDE's as long as IDE's don't want to evaluate your code as-is. ( ie:
> Java can make assumptions about what types are because of obvious lexical
> markers of what types they are, and can look at those type definitions to
> determine applicable methods. But its not foolproof, and if the type
> casting casts the wrong types and will fail at runtime, java will still
> complete methods for the assumed types as if they are valid )
> This vim extension provides most the features I look for in a Perl IDE,
> which isn't really much, and it provides a whole lot of things I never use.
> The difference though for me, is in Java, you literally can't work on any
> serious project without an IDE, some projects are so IDE centric that you
> can /only/ work on them with the projects choice of IDE, or it can be very
> non-obvious at least, how to work with a project with a different IDE.
> And for perly people, that requirement is a bit of a tall order. Many
> people dislike the dzil toolkit because of 'the installtime' ( kinda
> because they're not aware dzil authors do somewhat optimise for
> contribution to be possible without dzil :
> ),
> but I'd rather be installing dzil than eclipse, or some other bloated
> IDE, let alone a bloated IDE which is payware!.
> Though many Perl people can and do use IDE's for their stuff, I regularly
> try IDE's and find them unusable for Perl things, and it makes me feel like
> I'm lying down, thrashing, trying to get things done, essentially being
> hamstrung by IDE's sense of workflow, when I could just be spawning a text
> editor, making the fixes, and be done with it.
> --
> Kent

More information about the mailing list