3 ms·

Unix is a DE, no I about it. This isn’t a ding against Unix, the integration provided by IDEs is great for some types of work, but it’s also more hindrance tha

by pdpi 3y ago

Unix is a DE, no I about it. This isn’t a ding against Unix, the integration provided by IDEs is great for some types of work, but it’s also more hindrance than help for other types of work. Also, the toolset that you get from a typical Unix environment is more or less language agnostic, so you have your tool toolset available to you even when you’re working on something obscure with poor dedicated tooling support. That is not a replacement for IntelliJ knowing about my DI bindings, though.

Joker_vD 3y ago
Yeah, the article very conveniently ignores the "integrated" part of the IDE acronym. Which was one of the maint selling points of them: you don't have to cobble various small pieces of functionalty together by yourself, it's been figured out and done for you by the IDE developers once, now you can just write your programs.
- zeroCalories 3y ago
  I was super excited about customizing every little detail about my setup as a kid, but as an adult I'm pretty much using ubuntu lts and vscode because I can't be bothered to read a half assed repo on configuring my lsp.
- tharne 3y ago
  > Yeah, the article very conveniently ignores the "integrated" part of the IDE acronym. How's that? In unix (mostly) everything is a file, which in turn is just a stream of bytes that you can pass to any unix-y application, the output of which can be passed to any other unix-y application. That may not be your cup of tea or preferred environment, but it's very much integrated.
  - Koshkin 3y ago
    "Easily" integrable perhaps, then.
deleted 3y ago
[deleted]
criddell 3y ago
What’s an example of a type of work where an IDE is more of a hindrance?
- pdpi 3y ago
  Really big code bases, where your IDE grinds to a halt, for example.
  - deleted 3y ago
    [deleted]
- seanhunter 3y ago
  An example from my work experience: I was converting about 15 million lines of C++ code from pre-ansi to ansi-conformant compilers across 3 platforms. So step one was setting up a parallel build with each new compiler and step 2 was fixing the tens of thousands of compile errors. There’s no way you can tackle this in any IDE that I am aware of. You want to be able to use an overnight build and you want to be able to load the compiler output as a quickfix list[1]. Super easy in vim (and probably also in emacs) completely infeasible in any kind of normal IDE as far as I know. A lot of the time the error fix would boil down to some general rule so after I had fixed the error a bunch of times I would realise “ok when I see an error like this I need to change every ‘class’ in a template definition in this project into a ‘typename’ and every typedef of that class that looks like `typedef foo::<A,B>::iterator iterator` to `typedef typename foo::<A,B>::iterator iterator`[2]. Then once I realise the pattern I would write some find | perl -pie type thing to walk down the codebase from a certain point and fix all remaining instances of that particular error. These were typically more complex and subtle than the sort of autofixes/auto refactorings that I have seen available from IDEs although admittedly I’m sure the state of the art has improved beyond all recognition since then. [1] Each of the errors were of the type described by Alexandrescu in “Debugging the error novel” in that they were probably about 10 pages of ascii template hell per error times tens of thousands of errors. So I actually made two copies of the output. One went unadulterated into my quickfix list and one went into a separate buffer that I ran a bunch of regexes over to get them into a state where I could understand the error message. Then I could work down the qf list one error at a time while also paring down my “working error file” in parallel. [2] or something. It’s been a while.

by pdpi 3y ago

Joker_vD 3y ago

Yeah, the article very conveniently ignores the "integrated" part of the IDE acronym. Which was one of the maint selling points of them: you don't have to cobble various small pieces of functionalty together by yourself, it's been figured out and done for you by the IDE developers once, now you can just write your programs.

zeroCalories 3y ago
I was super excited about customizing every little detail about my setup as a kid, but as an adult I'm pretty much using ubuntu lts and vscode because I can't be bothered to read a half assed repo on configuring my lsp.
tharne 3y ago
> Yeah, the article very conveniently ignores the "integrated" part of the IDE acronym. How's that? In unix (mostly) everything is a file, which in turn is just a stream of bytes that you can pass to any unix-y application, the output of which can be passed to any other unix-y application. That may not be your cup of tea or preferred environment, but it's very much integrated.
- Koshkin 3y ago
  "Easily" integrable perhaps, then.

deleted 3y ago

[deleted]

criddell 3y ago

What’s an example of a type of work where an IDE is more of a hindrance?

pdpi 3y ago
Really big code bases, where your IDE grinds to a halt, for example.
- deleted 3y ago
  [deleted]
seanhunter 3y ago
An example from my work experience: I was converting about 15 million lines of C++ code from pre-ansi to ansi-conformant compilers across 3 platforms. So step one was setting up a parallel build with each new compiler and step 2 was fixing the tens of thousands of compile errors. There’s no way you can tackle this in any IDE that I am aware of. You want to be able to use an overnight build and you want to be able to load the compiler output as a quickfix list[1]. Super easy in vim (and probably also in emacs) completely infeasible in any kind of normal IDE as far as I know. A lot of the time the error fix would boil down to some general rule so after I had fixed the error a bunch of times I would realise “ok when I see an error like this I need to change every ‘class’ in a template definition in this project into a ‘typename’ and every typedef of that class that looks like `typedef foo::<A,B>::iterator iterator` to `typedef typename foo::<A,B>::iterator iterator`[2]. Then once I realise the pattern I would write some find | perl -pie type thing to walk down the codebase from a certain point and fix all remaining instances of that particular error. These were typically more complex and subtle than the sort of autofixes/auto refactorings that I have seen available from IDEs although admittedly I’m sure the state of the art has improved beyond all recognition since then. [1] Each of the errors were of the type described by Alexandrescu in “Debugging the error novel” in that they were probably about 10 pages of ascii template hell per error times tens of thousands of errors. So I actually made two copies of the output. One went unadulterated into my quickfix list and one went into a separate buffer that I ran a bunch of regexes over to get them into a state where I could understand the error message. Then I could work down the qf list one error at a time while also paring down my “working error file” in parallel. [2] or something. It’s been a while.