28 ms·

Languages have evolved. Now developers EXPECT languages to come with a FREE suit of command line tools for linting, static analysis, formatting, package managem

Languages have evolved. Now developers EXPECT languages to come with a FREE suit of command line tools for linting, static analysis, formatting, package management and what not. FROM there ANY text editor should be able to take advantage of all these command line tools to provide a good developer experience. The time of bloated IDEs is over. And you're right, I need to be able to run all CI tools the same I do on my development machine and the CI server. Obviously, WYSIWYG and other graphical builders will always need a specific IDE in order to do RAD, but these are special cases, not the norm anymore. Nothing prevent jetbrains from selling CLI tools that perform all the tasks in their IDE, especially when many of their IDE do rely on open source CLI tools at first place. But If I'm developing say an Android app and I'm not the design integrator, I shouldn't have to fire an slow and heavy IDE just to write a bunch of Java classes. I have my maven manifest and it should be all I need to compile a project.

rfoo 6y ago
> Now developers EXPECT languages to come with a FREE suit of command line tools for linting, static analysis, formatting, package management and what not. The key selling point of Intellij IDEA is they come with semantic refactoring tools, for something like "move this method into its parent class" or "extract the selected methods to a new interface", which is still rarely seen in the wild, and didn't get mentioned at all in your list, but it saves real time.
- mumblemumble 6y ago
  It saves real time if you write your code the way IntelliJ wants you to write your code. If you structure things differently - say, by steering clear of subclass inheritance, or keeping interfaces small, or not using the Bean pattern, then you can pretty quickly discover that there aren't all that many IDE refactorings that you actually use. At this point, most the refactorings and code actions that I'm actually using exist in vscode as well; IntelliJ's main advantage is that I'm (somewhat) more able to use them efficiently without taking my hands off the keyboard.
  - defnotashton2 6y ago
    Extract interface, implement interface, extract method, move(to own file) only exist for go and c# via jet rains and are practical for anyone writing real world code.
    - jolux 6y ago
      Visual Studio does at least some of those for C#.
      - akiselev 6y ago
        And vscode has them for Typescript at the least, I suspect several other languages support them.
    - misa7499 6y ago
      VSCode C# extension supports all of those.
  - jolux 6y ago
    They’re immensely useful tools when working in large poorly-structured codebases, and they are more than worth it when dealing with stuff like that.
MrDresden 6y ago
In the case of developing a Android application there is nothing keeping you from using the tool of your choice to write the code in, and simply using what ever plugins are available to your editor of choice to run the compile steps, deployment to a device or an emulator etc. After all you only need a single line command to compile a properly configured Android project into a releasable APK. But when I want to write my code, get correct linting, inline documentation, Java-to-Kotlin conversion of old code, the whole range of interacting with the device I am running my code on, management of my Gradle tasks, VCS integration, Task contexts, remote connections to test databases (and the whole other metric ton of features I wont get into) I will always take Android Studio over what ever flavour of the year text editor. I really enjoy using VS code, but it is no IDE.
tabtab 6y ago
Re: Obviously, WYSIWYG and other graphical builders will always need a specific IDE in order to do RAD, but these are special cases, not the norm anymore. I don't know why it died, WYSIWYG and GUI-friendly IDE's allowed higher productivity in that "one-man-bands" (small staff) could do the entire project. Now development is often layered into specialists. Things like UI design and ORM's have longer learning curves, which emphasizes specialists. But staff is larger per feature: less productive. (There are many times I wanted to shoot Bootstrap in the head when I couldn't get it to act how I wanted. Something in WYSIWYG that would take 20 seconds becomes a 2 day trial-and-error session in Bootstrap.) WYSIWYG/GUI-IDE saved money. Most businesses don't run their internal productivity software on mobile anyhow. "Progressive" UI's are a money sink in practice. The trend predictors got it WRONG: desktops live on in biz. Our anti-state-GUI web standards don't help. Businesses really want cheap rich desktop-like GUI's for productivity software. I'm not against flow-based layouts, but they should be an option, along with WYSIWYG.
- dakna 6y ago
  > Businesses really want cheap rich desktop-like GUI's for productivity software Can I ask where you you see this demand, is it industry specific? I was under the impression that the benefits (easy deployment to a known runtime aka the browser, open ports (80/443) in the firewall, large developer pool, potentially cross-platform use) outweigh the UI shortcomings and budgets were shifted to web-based productivity software.
  - tabtab 6y ago
    The features you list are not necessarily mutually exclusive, but too many think they are, and that's the problem. For some reason people seem to think it's either rich GUI -or- web. With a decent stateful GUI markup standard, we can have the best of both. HTML wasn't meant to be stateful nor for rich interactive GUI's. Faking it with JavaScript has proved a bloated crashy mess. End users who care about productivity want rich GUI's. Rich GUI's use screen real-estate better than "progressive" web apps and have abilities like right-click, rollover text, etc.; and it's cheaper to develop because they (optionally) can use WYWIWYG for many parts of it. WYWIWYG is just plain cheaper and easier to get right. You don't need "flow layout" specialists who can tame sucky CSS/DOM, which makes alchemy look logical. Remember that businesses don't really care how software works as long as it does the job and is affordable in creation and maintenance. The bloated web stacks are not. It's too much code to do the same thing UI-fit tools did with less because they were closer to the CRUD/GUI domain itself. Web stacks are too fucking layered such that you spend most of the time managing communication between layers instead of on real biz logic. I stand by this and if you look at the code you should agree. We DEVOLVED. Current web standards may be fine for social media, but not real work. We let the "cool stuff" pollute real work in cubicle-land. Oh, and git off my lawn! ;-)
hota_mazi 6y ago
> The time of bloated IDEs is over. I find this pretty dumbfounding considering the amount of efforts that goes into IDEA, Eclipse, Visual Studio, and X Code on a daily basis. Also, watch how VS Code (and other text editors) are slowly turning into full blown IDE's as well. The code we write today has never been more complex, it requires matching complex tools.
- tuatoru 6y ago
  > The code we write today has never been more complex, it requires matching complex tools. And Intellij's products come from decades-old thinking about how to manage that complexity. They're not good enough; for many people they don't help manage complexity. They just increase the confusion.
winrid 6y ago
IntelliJ is hardly bloated. In some cases it barely uses more memory than VS Code. I have Webstorm with 15 projects open using 500mb of ram, and IntelliJ using about 800 on a larger Java project.

rfoo 6y ago

> Now developers EXPECT languages to come with a FREE suit of command line tools for linting, static analysis, formatting, package management and what not. The key selling point of Intellij IDEA is they come with semantic refactoring tools, for something like "move this method into its parent class" or "extract the selected methods to a new interface", which is still rarely seen in the wild, and didn't get mentioned at all in your list, but it saves real time.

mumblemumble 6y ago
It saves real time if you write your code the way IntelliJ wants you to write your code. If you structure things differently - say, by steering clear of subclass inheritance, or keeping interfaces small, or not using the Bean pattern, then you can pretty quickly discover that there aren't all that many IDE refactorings that you actually use. At this point, most the refactorings and code actions that I'm actually using exist in vscode as well; IntelliJ's main advantage is that I'm (somewhat) more able to use them efficiently without taking my hands off the keyboard.
- defnotashton2 6y ago
  Extract interface, implement interface, extract method, move(to own file) only exist for go and c# via jet rains and are practical for anyone writing real world code.
  - jolux 6y ago
    Visual Studio does at least some of those for C#.
    - akiselev 6y ago
      And vscode has them for Typescript at the least, I suspect several other languages support them.
  - misa7499 6y ago
    VSCode C# extension supports all of those.
- jolux 6y ago
  They’re immensely useful tools when working in large poorly-structured codebases, and they are more than worth it when dealing with stuff like that.

MrDresden 6y ago

In the case of developing a Android application there is nothing keeping you from using the tool of your choice to write the code in, and simply using what ever plugins are available to your editor of choice to run the compile steps, deployment to a device or an emulator etc. After all you only need a single line command to compile a properly configured Android project into a releasable APK. But when I want to write my code, get correct linting, inline documentation, Java-to-Kotlin conversion of old code, the whole range of interacting with the device I am running my code on, management of my Gradle tasks, VCS integration, Task contexts, remote connections to test databases (and the whole other metric ton of features I wont get into) I will always take Android Studio over what ever flavour of the year text editor. I really enjoy using VS code, but it is no IDE.

tabtab 6y ago

Re: Obviously, WYSIWYG and other graphical builders will always need a specific IDE in order to do RAD, but these are special cases, not the norm anymore. I don't know why it died, WYSIWYG and GUI-friendly IDE's allowed higher productivity in that "one-man-bands" (small staff) could do the entire project. Now development is often layered into specialists. Things like UI design and ORM's have longer learning curves, which emphasizes specialists. But staff is larger per feature: less productive. (There are many times I wanted to shoot Bootstrap in the head when I couldn't get it to act how I wanted. Something in WYSIWYG that would take 20 seconds becomes a 2 day trial-and-error session in Bootstrap.) WYSIWYG/GUI-IDE saved money. Most businesses don't run their internal productivity software on mobile anyhow. "Progressive" UI's are a money sink in practice. The trend predictors got it WRONG: desktops live on in biz. Our anti-state-GUI web standards don't help. Businesses really want cheap rich desktop-like GUI's for productivity software. I'm not against flow-based layouts, but they should be an option, along with WYSIWYG.

dakna 6y ago
> Businesses really want cheap rich desktop-like GUI's for productivity software Can I ask where you you see this demand, is it industry specific? I was under the impression that the benefits (easy deployment to a known runtime aka the browser, open ports (80/443) in the firewall, large developer pool, potentially cross-platform use) outweigh the UI shortcomings and budgets were shifted to web-based productivity software.
- tabtab 6y ago
  The features you list are not necessarily mutually exclusive, but too many think they are, and that's the problem. For some reason people seem to think it's either rich GUI -or- web. With a decent stateful GUI markup standard, we can have the best of both. HTML wasn't meant to be stateful nor for rich interactive GUI's. Faking it with JavaScript has proved a bloated crashy mess. End users who care about productivity want rich GUI's. Rich GUI's use screen real-estate better than "progressive" web apps and have abilities like right-click, rollover text, etc.; and it's cheaper to develop because they (optionally) can use WYWIWYG for many parts of it. WYWIWYG is just plain cheaper and easier to get right. You don't need "flow layout" specialists who can tame sucky CSS/DOM, which makes alchemy look logical. Remember that businesses don't really care how software works as long as it does the job and is affordable in creation and maintenance. The bloated web stacks are not. It's too much code to do the same thing UI-fit tools did with less because they were closer to the CRUD/GUI domain itself. Web stacks are too fucking layered such that you spend most of the time managing communication between layers instead of on real biz logic. I stand by this and if you look at the code you should agree. We DEVOLVED. Current web standards may be fine for social media, but not real work. We let the "cool stuff" pollute real work in cubicle-land. Oh, and git off my lawn! ;-)

hota_mazi 6y ago

> The time of bloated IDEs is over. I find this pretty dumbfounding considering the amount of efforts that goes into IDEA, Eclipse, Visual Studio, and X Code on a daily basis. Also, watch how VS Code (and other text editors) are slowly turning into full blown IDE's as well. The code we write today has never been more complex, it requires matching complex tools.

tuatoru 6y ago
> The code we write today has never been more complex, it requires matching complex tools. And Intellij's products come from decades-old thinking about how to manage that complexity. They're not good enough; for many people they don't help manage complexity. They just increase the confusion.

winrid 6y ago

IntelliJ is hardly bloated. In some cases it barely uses more memory than VS Code. I have Webstorm with 15 projects open using 500mb of ram, and IntelliJ using about 800 on a larger Java project.