4 ms·

No, it's more like the IDE is augmenting your brain and fingers. The code comes out readable, but you only have to type a fraction of the characters. It's a cod

No, it's more like the IDE is augmenting your brain and fingers. The code comes out readable, but you only have to type a fraction of the characters. It's a code-writing assistant robot. Also, it makes APIs incredibly discoverable. Not sure what a `IQueryable` provides? IQueryable iq = null; iq. and scroll through the popup. Instant one-line descriptions are available in the tooltips, and you can get full documentation with F1. you've ever experienced this, it's REALLY hard to go back to Emacs. It's incredibly well done. (edit: formatting)

neeleshs 15y ago
Agree on the discovery part, this is the biggest reason why I stay away from vim.
- illicium 15y ago
  http://www.vim.org/scripts/script.php?script_id=1520 http://www.vim.org/scripts/script.php?script_id=1520
thenduks 15y ago
That doesn't sound all that good to me. My steps to finding what IQueryable provides: * Cmd+Tab to Chrome * Cmd+L for location focus * \IQueryable searches DuckDuckGo for IQueryable and takes me to first result I get to use the editor I want (hint, not visual studio), and I know a lot more about IQueryable anyway and can continue poking around in the docs to learn more about the 'nearby' bits of the API. I don't really want my editor to write code for me after only a fraction of the characters. I like writing code. I agree with Inufu, I feel like completion of more than, say, IQu[tab] is starting to show redundancy I'd prefer not to have in the first place.
- andypants 15y ago
  "Here's how to instantly find documentation on something." "That doesn't sound all that good to me. Here's how I do it in multiple steps, in a different window!" Do you see the problem here?
  - slowpoke 15y ago
    No, I don't. He's using different tools for different jobs, which is the way it should be. Not an integrated mess of a thousand and one things that should be stand-alone programs with intercommunication ability. Those who don't understand UNIX are forever doomed to re-implement it - poorly. Which is the story of every IDE ever.
    - koko775 15y ago
      As if the goal or intention were to approach UNIX's philosophy. UNIX is practically by definition decoupled. Integrated Development Environments are by definition integrated. I spent years hating Java and embracing vim, but as I tried to shape my environment more, I grew increasingly frustrated. Finally, I was forced by necessity to use Eclipse and Maven with Java, and the lightbulb turned on for me. Any language that takes 30-40% less code to do something for you is taking away some freedom. They're making convention easy but can make escaping it to be hard, or may slow down because of more dynamic-ness, or some other tradeoff. And there are many good tradeoffs to be had when creating programming languages, of course. The deal with Java is that it is the pedant of languages. Half-answers and hand-waving to how objects interact (i.e. duck-typing) aren't good enough for it. This makes libraries or APIs very, very easy to reason about, because if it doesn't access to that information then that means that the library or API is broken or intentionally hiding those details from you. But on the other hand, it enforces a kind of light, but still present, agreement between classes on their relationships to each other. The point at which your thoughts on IDE come into this is that because Java has a very rigid structure, it can make sweeping code changes at massive scale. This is something that, with shallower insight into the language, or without insight into the flow of code through a method (i.e. checking for dead code or invalid assignments), and so on, would take a massive number of man-hours to duplicate, or make use of the exact same code the IDEs themselves have written for the purpose (i.e. emacs and vim are capable of delegating certain functions to eclipse). Decoupling it in the UNIX way doesn't really make a whole lot of sense when everything is very interrelated in nature. As well as generate, but given that some people think that if code can be generated, it should be done at runtime by the language instead, I don't want to argue this too hard in this reply. They're not wrong but they sure aren't right.

neeleshs 15y ago

Agree on the discovery part, this is the biggest reason why I stay away from vim.

illicium 15y ago
http://www.vim.org/scripts/script.php?script_id=1520 http://www.vim.org/scripts/script.php?script_id=1520

thenduks 15y ago

That doesn't sound all that good to me. My steps to finding what IQueryable provides: * Cmd+Tab to Chrome * Cmd+L for location focus * \IQueryable searches DuckDuckGo for IQueryable and takes me to first result I get to use the editor I want (hint, not visual studio), and I know a lot more about IQueryable anyway and can continue poking around in the docs to learn more about the 'nearby' bits of the API. I don't really want my editor to write code for me after only a fraction of the characters. I like writing code. I agree with Inufu, I feel like completion of more than, say, IQu[tab] is starting to show redundancy I'd prefer not to have in the first place.

andypants 15y ago
"Here's how to instantly find documentation on something." "That doesn't sound all that good to me. Here's how I do it in multiple steps, in a different window!" Do you see the problem here?
- slowpoke 15y ago
  No, I don't. He's using different tools for different jobs, which is the way it should be. Not an integrated mess of a thousand and one things that should be stand-alone programs with intercommunication ability. Those who don't understand UNIX are forever doomed to re-implement it - poorly. Which is the story of every IDE ever.
  - koko775 15y ago
    As if the goal or intention were to approach UNIX's philosophy. UNIX is practically by definition decoupled. Integrated Development Environments are by definition integrated. I spent years hating Java and embracing vim, but as I tried to shape my environment more, I grew increasingly frustrated. Finally, I was forced by necessity to use Eclipse and Maven with Java, and the lightbulb turned on for me. Any language that takes 30-40% less code to do something for you is taking away some freedom. They're making convention easy but can make escaping it to be hard, or may slow down because of more dynamic-ness, or some other tradeoff. And there are many good tradeoffs to be had when creating programming languages, of course. The deal with Java is that it is the pedant of languages. Half-answers and hand-waving to how objects interact (i.e. duck-typing) aren't good enough for it. This makes libraries or APIs very, very easy to reason about, because if it doesn't access to that information then that means that the library or API is broken or intentionally hiding those details from you. But on the other hand, it enforces a kind of light, but still present, agreement between classes on their relationships to each other. The point at which your thoughts on IDE come into this is that because Java has a very rigid structure, it can make sweeping code changes at massive scale. This is something that, with shallower insight into the language, or without insight into the flow of code through a method (i.e. checking for dead code or invalid assignments), and so on, would take a massive number of man-hours to duplicate, or make use of the exact same code the IDEs themselves have written for the purpose (i.e. emacs and vim are capable of delegating certain functions to eclipse). Decoupling it in the UNIX way doesn't really make a whole lot of sense when everything is very interrelated in nature. As well as generate, but given that some people think that if code can be generated, it should be done at runtime by the language instead, I don't want to argue this too hard in this reply. They're not wrong but they sure aren't right.