7 ms·

The thing I hate most about IDEs is when they insinuate themselves into a project's development workflow so deeply that you can't make do without them. Do I ha

by bccdee 5y ago

The thing I hate most about IDEs is when they insinuate themselves into a project's development workflow so deeply that you can't make do without them. Do I have to spin up a whole session of the IDE just to run my test suite? Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter? Is there so much boilerplate or XML or whatever within the frameworks we're using that writing or changing code is impossible without automation? These are bad things. An IDE can be a powerful abstraction, but when the underlying layer it's abstracting over becomes inaccessible, then all it's doing is adding more complexity by obscuring concrete details.

tester756 5y ago
>An IDE can be a powerful abstraction how IDE "can" be an abstraction? It's tool, it's wrapper (e.g button over commandline commands), but abstraction?
- xxpor 5y ago
  The line between the two isn't very clear, nor is it productive to really argue about it, IMO
  - tester756 5y ago
    >nor is it productive to really argue about it I do agree
    - Nevermark 5y ago
      It was still a good question! There is a line between a tool: A) that makes managing relevant information more efficient, while not hiding any of that information. B) vs. a tool that hides some details, providing a tradeoff of higher productivity MOST of the time, but at the cost of requiring a fall back tool on other (rare?) occasions. I would say, once a tool stops providing access to any (even rarely) relevant details, it has become an abstraction.
Yajirobe 5y ago
> The thing I hate most about IDEs is when they insinuate themselves into a project's development workflow so deeply that you can't make do without them. Isn't this the case with Android Studio? Is it even possible to do Android development without Android Studio?
- papaf 5y ago
  Is it even possible to do Android development without Android Studio? Oh yes: https://www.lambdanative.org/ https://www.lambdanative.org/
- Kwpolska 5y ago
  You can build an app from the command line with Gradle: https://developer.android.com/studio/build/building-cmdline https://developer.android.com/studio/build/building-cmdline That said, it would be quite difficult to write anything substantial without Android Studio.
jeffeld 5y ago
"An IDE can be a powerful abstraction, but when the underlying layer it's abstracting over becomes inaccessible, then all it's doing is adding more complexity by obscuring concrete details" This. All day long.
- squarefoot 5y ago
  And night, and the whole week. I can edit, compile and install my kernel and all its drivers in a few command lines from shell, why more and more projects, most way simpler than a kernel, ask me to install for example VSC just to build them? Give me a Makefile and possibly enough instructions to integrate its options into the favorite IDE, but making the IDE a requirement, especially for small projects or those one simply wants to build and install, adds only more complexity.
rzwitserloot 5y ago
> Do I have to spin up a whole session of the IDE just to run my test suite? In the java ecosystem at least, the answer is no. But in highly CI-based situations, the answer is still no, but you DO need the CI system to be up, and the only way to run a test at all is to just commit something and see the CI system run it, e.g. because the tests require a database engine that isn't installed on your development machine. I'm not saying that's a good idea, just saying that I have seen that in real (as in, for pay and for real eyeballs) dev teams. I've never observed 'I only know how to run my tests inside the IDE'. IDEs (again, this is mostly speaking from the perspective of the java ecosystem) use build tools as project definitions, and those build tests all know how to run the test suite from the command line. `mvn test` is all you need to type. > Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter? No, it's `mvn install` or `mvn build` or whatever take on 'build' you are looking for specifically. If you ditch your IDE, __nothing__ whatsoever would change: Your build is _still_ based on a build tool. (it better be, in the sense that trying to run the build by hand or by patching a bunch of shell scripts together is almost 100% correlated with very low quality dev teams in my experience). In other words... what are you on about? IDEs don't abstract such details away to extreme degrees. In fact, insofar that they ever did (generally in GUI builders, which, what with the web and languages like java and Adobe Air and silverlight falling by the wayside in the past few years for front-end dev - are kinda dead), the new takes on such tools all very explicitly keep the whole 'actually this just edits a text file of some sort and this automated click-the-GUI-together tool is bending over backwards to ensure that the underlying file looks as close as possible to what you would write by hand.
- szatkus 5y ago
  In my current organization I saw a project, where there is no Maven. The build system is a couple of configuration files for Eclipse IDE and that's the only way to run it. I'm glad I didn't have to do anything around that.
  - AmpsterMan 5y ago
    My team used to have stuff off that nature after we inherited the code base. Acquisition and movement of HQ meant a brand new team on a 15 year old B2B SaaS. Trying to move away from the combination of shell scripts, perl scripts, eclipse config, etc. Over to Gradle has been painful, but with it for onboarding new devs.
eitland 5y ago
> Do I have to spin up a whole session of the IDE just to run my test suite? Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter? Can you say what language/platform you talk abojt here? I currently work in Kotlin with IntelliJ where sadly the only working IDE is IntelliJ,but you can build it just fine and even fix bugs using whatever editor you want. I also maintain a lot of React code, used to work on .Net Core and some plain old C# before Core, I've maintained Angular and before that Java, older Delphi versions and even PHP. The only projects that had the problem you talk about were - Visual Studio (not Visul Studio Code) projects from before .Net core - and old Delphi projects. That said, I'm kind of stuck with IntelliJ now because of Kotlin (which is an awesome language) but I miss NetBeans a lot and how it - instead of saving everything in its own configuration files - simply accepted Maven .pom files as configuration, meaning uncluttered repos and still having all config synced and up to date everywhere. (Maven is well though out so if you just accept the defaults the files are small and contain only the things they need to contain like name, namespace and version, dependencies and necessary configuration.)
- bccdee 5y ago
  I was mostly complaining about an old Visual Studio project I used to work on.
  - eitland 5y ago
    Then we agree very much. I can happily say that this problem doesn't exist on the other platforms I deal with but I guess you already know :-)
jeffterns8 5y ago
You mean when you or a team chooses to embed them into the project's workflow to that degree? Or are you talking about the worst IDEs no one should use while sounding like it is a general IDE issue with the industry standards? Any decent IDE doesn't enforce such things, it is something questionable devs choose to incorporate. You may inadvertently do this if you don't know an IDE, and try to use excessive features available, but that's still on you for doing so. It shouldn't have been a decision made by someone lacking in knowledge/experience, whether a junior dev or a senior selecting an unknown tool without proper evaluation. Or are you implying such features from IDEs can somehow be attained by non-IDE toolchains that don't also ingrain you in those toolchains to make use of said features?

by bccdee 5y ago

tester756 5y ago

>An IDE can be a powerful abstraction how IDE "can" be an abstraction? It's tool, it's wrapper (e.g button over commandline commands), but abstraction?

xxpor 5y ago
The line between the two isn't very clear, nor is it productive to really argue about it, IMO
- tester756 5y ago
  >nor is it productive to really argue about it I do agree
  - Nevermark 5y ago
    It was still a good question! There is a line between a tool: A) that makes managing relevant information more efficient, while not hiding any of that information. B) vs. a tool that hides some details, providing a tradeoff of higher productivity MOST of the time, but at the cost of requiring a fall back tool on other (rare?) occasions. I would say, once a tool stops providing access to any (even rarely) relevant details, it has become an abstraction.

Yajirobe 5y ago

> The thing I hate most about IDEs is when they insinuate themselves into a project's development workflow so deeply that you can't make do without them. Isn't this the case with Android Studio? Is it even possible to do Android development without Android Studio?

papaf 5y ago
Is it even possible to do Android development without Android Studio? Oh yes: https://www.lambdanative.org/ https://www.lambdanative.org/
Kwpolska 5y ago
You can build an app from the command line with Gradle: https://developer.android.com/studio/build/building-cmdline https://developer.android.com/studio/build/building-cmdline That said, it would be quite difficult to write anything substantial without Android Studio.

jeffeld 5y ago

"An IDE can be a powerful abstraction, but when the underlying layer it's abstracting over becomes inaccessible, then all it's doing is adding more complexity by obscuring concrete details" This. All day long.

squarefoot 5y ago
And night, and the whole week. I can edit, compile and install my kernel and all its drivers in a few command lines from shell, why more and more projects, most way simpler than a kernel, ask me to install for example VSC just to build them? Give me a Makefile and possibly enough instructions to integrate its options into the favorite IDE, but making the IDE a requirement, especially for small projects or those one simply wants to build and install, adds only more complexity.

rzwitserloot 5y ago

> Do I have to spin up a whole session of the IDE just to run my test suite? In the java ecosystem at least, the answer is no. But in highly CI-based situations, the answer is still no, but you DO need the CI system to be up, and the only way to run a test at all is to just commit something and see the CI system run it, e.g. because the tests require a database engine that isn't installed on your development machine. I'm not saying that's a good idea, just saying that I have seen that in real (as in, for pay and for real eyeballs) dev teams. I've never observed 'I only know how to run my tests inside the IDE'. IDEs (again, this is mostly speaking from the perspective of the java ecosystem) use build tools as project definitions, and those build tests all know how to run the test suite from the command line. `mvn test` is all you need to type. > Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter? No, it's `mvn install` or `mvn build` or whatever take on 'build' you are looking for specifically. If you ditch your IDE, __nothing__ whatsoever would change: Your build is _still_ based on a build tool. (it better be, in the sense that trying to run the build by hand or by patching a bunch of shell scripts together is almost 100% correlated with very low quality dev teams in my experience). In other words... what are you on about? IDEs don't abstract such details away to extreme degrees. In fact, insofar that they ever did (generally in GUI builders, which, what with the web and languages like java and Adobe Air and silverlight falling by the wayside in the past few years for front-end dev - are kinda dead), the new takes on such tools all very explicitly keep the whole 'actually this just edits a text file of some sort and this automated click-the-GUI-together tool is bending over backwards to ensure that the underlying file looks as close as possible to what you would write by hand.

szatkus 5y ago
In my current organization I saw a project, where there is no Maven. The build system is a couple of configuration files for Eclipse IDE and that's the only way to run it. I'm glad I didn't have to do anything around that.
- AmpsterMan 5y ago
  My team used to have stuff off that nature after we inherited the code base. Acquisition and movement of HQ meant a brand new team on a 15 year old B2B SaaS. Trying to move away from the combination of shell scripts, perl scripts, eclipse config, etc. Over to Gradle has been painful, but with it for onboarding new devs.

eitland 5y ago

> Do I have to spin up a whole session of the IDE just to run my test suite? Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter? Can you say what language/platform you talk abojt here? I currently work in Kotlin with IntelliJ where sadly the only working IDE is IntelliJ,but you can build it just fine and even fix bugs using whatever editor you want. I also maintain a lot of React code, used to work on .Net Core and some plain old C# before Core, I've maintained Angular and before that Java, older Delphi versions and even PHP. The only projects that had the problem you talk about were - Visual Studio (not Visul Studio Code) projects from before .Net core - and old Delphi projects. That said, I'm kind of stuck with IntelliJ now because of Kotlin (which is an awesome language) but I miss NetBeans a lot and how it - instead of saving everything in its own configuration files - simply accepted Maven .pom files as configuration, meaning uncluttered repos and still having all config synced and up to date everywhere. (Maven is well though out so if you just accept the defaults the files are small and contain only the things they need to contain like name, namespace and version, dependencies and necessary configuration.)

bccdee 5y ago
I was mostly complaining about an old Visual Studio project I used to work on.
- eitland 5y ago
  Then we agree very much. I can happily say that this problem doesn't exist on the other platforms I deal with but I guess you already know :-)

jeffterns8 5y ago

You mean when you or a team chooses to embed them into the project's workflow to that degree? Or are you talking about the worst IDEs no one should use while sounding like it is a general IDE issue with the industry standards? Any decent IDE doesn't enforce such things, it is something questionable devs choose to incorporate. You may inadvertently do this if you don't know an IDE, and try to use excessive features available, but that's still on you for doing so. It shouldn't have been a decision made by someone lacking in knowledge/experience, whether a junior dev or a senior selecting an unknown tool without proper evaluation. Or are you implying such features from IDEs can somehow be attained by non-IDE toolchains that don't also ingrain you in those toolchains to make use of said features?