1. 7
  1.  

  2. 7

    TLDR: Author used several bad IDEs, which crashed to the point of rebooting so that restarting after a reboot alsotook a long while.

    Well, now I really want to know on what kind of potato the author was running which IDEs. JetBrains IDEA is not lightweight but I’d used it for 4 years on an x230 (ok, i7 with 16GB and SSD) without any problems. Multiple projects, multiple languages, multiple VMs running at the same time. Now I use QtCreator and it’s a joy.

    Not using IDEs is fine, but the concept of an IDE is absolutely not the problem here.

    1. 1

      Intellij crashes on me at times. Are you sure you haven’t had any problems?

      Edit: Don’t take my question as an endorsement of this article, which it is not. 🙂

      1. 1

        You never have not any problems ;) But I’ve definitely had less problems than when using non-IDEs. (Sure it crashed once in a while or was stuck at “indexing” - but it’s given me less problems than, say, my browser, IRC client, mail client or anything else. Maybe I was just lucky :P) But just opening many files and switching between them multiple times per minute, resplitting panes, etc. It’s doable in vim/tmux/etcc (for me) but there’s no “intuitive flow” and forget about plain editors.

        1. 0

          wink wrote:

          … ;) …

      2. 1

        JetBrains has some quality IDE’s. For me, PhpStorm has features that I haven’t found in other IDE’s let alone text editors. I’m guessing this is similar to other languages too. For example IDE’s that support and extend hot swapping for Java.

      3. 4

        Seems like just an advertisement for the service that’s hosting this blog post.

        1. 3

          Corporate blogs usually are (with some exceptions).

        2. 3

          That’s why even when I worked with an IDE I rarely used the debugger. Instead I prefer to use debug prints.

          This author lost all credibility with me here. One simply cannot be effective working with large legacy code bases without using the debugger. So many things are obvious when you can step through the code.

          1. 3

            So, you’re right… but when code bases become too large and legacy, you lose the ability to use a debugger.

            I was hacking on chromium for a raspberry pi. Starting it with GDB took ages, with many gigabytes of SWAP space (and SWAP on an SD card is not exactly fast…), and GDB wasn’t even terribly useful because of how Chromium does multiple processes (at least I wasn’t able to get much use of it with my current knowledge of GDB and googling skills) Trying to start it in Valgrind would crash it after quite a few minutes, regardless of the amount of swap space. Recompiling from a release build to a debug build resulted in a day lost to waiting for Chromium to compile, and it turned out Chromium’s stack trace feature doesn’t even work properly on ARM (at least that was my experience).

            Sometimes, printfs truly are your only choice.

            1. 1

              Sometimes, printfs truly are your only choice.

              Maybe, but not in your example. One can remote debug with most debuggers, gdb included. I’m not proficient with gdb, google turns up many links though. I’ve been a “hero” more than once remote debugging java app servers for example.

            2. 1

              I, and most of my teammates, regularly use printf debugging when we have to debug GCC and the binutils. It works just fine.

              1. 1

                Sure printf can be adequate and get the job done, but the difference is drilling straight down to the problem in minutes as opposed the theorizing, sprinkling printfs about, recompiling, reviewing, and repeating n times.

                I once read a blog post (which I can’t find now) about a debugging story that really opened my eyes to what was possible. This spurred me to spend time learning the tools in my own domain, which have paid huge dividends over my career.

                Use what thou shalt, I’m simply advocating for using the tools available. They really can make a difference.

                1. 1

                  Don’t get me wrong, it’s not that I don’t use a debugger, it’s just that sometimes it’s a crappy tool for the job. And a lot of those times end up being, say, when you’re trying to debug a compiler optimization that you’re not sure how it occurs. Does it happen right away? On the 50,000th iteration? Only when the register allocator has a specific configuration that is hard to describe? Walking through the execution can take literally hours in these cases (and you can script it, but if you don’t know what you’re looking for, what’s the point?). It’s likely faster to instrument the code, generate a giant log file, study the log file, then fire up the debugger if you haven’t already figured out the problem after searching through the log.

                  I recently had to debug a linker issue and I didn’t know the structure of the linker very well. I had a rough idea where the problem might be occuring. I fired up the debugger and set a breakpoint on my guess: the breakpoint was never hit. I could have kept doing that, or traced through from main, or I could just look at the code. I opted to look. Studying the code a bit I managed to find the entry point but then I realized I had to understand the data structure it was working with. I tried printing it in the debugger and it was… not illuminating. I studied some more code and once I had a grasp on it, I had a pretty good idea what the problem was. I verified the problem in the debugger shortly thereafter.

                  An interactive debugger was really useful here, but I can’t say it was the reason I figured things out. They’re good for exploration of the execution space, especially when you have a good grasp on where/when the problem occurs. They’re less useful when you don’t know the basic code structure, and they’re even less useful when you don’t know much about the data structures being manipulated (and your problem is actually a data problem). But for verification, they can be insanely useful.

            3. 2

              Why does he have an embedded tweet linking to his own article?

              1. 1

                Tom Ryder did a good series on using Unix as an IDE: https://sanctum.geek.nz/arabesque/series/unix-as-ide/

                1. 1

                  would love to know what extensions he’s using in sublime for compile checking

                  1. 3

                    I have no idea if they’ve been using it, but a possibility could be Facebook’s fbinfer or Findbugs. I have used neither, so I can’t testify, but from what I’ve seen, these seem to do their task quite all right.

                    1. 1

                      nice, ya i’ll give them a go

                    2. 2

                      Open another terminal window. Run make. For each error that pops out, fix it with the editor. Rerun make as required.

                      It’s not unusual for me to have three terminals open each with my preferred text editor, another term open for making the project, and another term open for running and debugging. I’ve yet to find an IDE that won’t crash on me (for over 25 years I’ve yet to find an IDE that lasts longer than 5 minutes without crashing).

                      1. 1

                        And with the Acme editor this process is even simpler, for every error that pops up in make (running in an acme window), you just right click on the file name and it will open or switch to the file with the cursor on the right line/column.

                        1. 4

                          Actually I found recently that Vim can do this, if you do:

                          make > errors.log
                          lint > errors2.log  # another good example
                          vim errors.log
                          

                          Then just do “gf” over the error messages, and it parses “foo.py:32” in the correct way and jumps there! Works surprisingly well.

                          Unix!

                          1. 2

                            That’s really cool, though the part I like about acme is that it does all this composition of programs in a way that allows even a computer illiterate to use it. I mean anybody can right click on some text.

                          2. 1

                            Yes, my text editor can do that. I even played around with that feature for a bit. I still find it faster using separate terminal windows.

                            1. 1

                              I tend to use acme windows as my terminal, so opening another acme window is sort of like running a separate terminal.

                              Though I do want to explore the idea of the “Universal user interface”, acme is really nice, but it’s a shame that it manages it’s own windows, it would be interesting to have a version of acme that worked a bit more like Kakoune. The text editor could simply be a graphical shell that talks to a text editing server and to other programs and doesnt actually do anything, that way it could probably be lightning fast, super flexible and easier to prove correct.

                              1. 2

                                it’s a shame that it manages it’s own windows, it would be interesting to have a version of acme

                                I’m fantasticating about this from the other perspective: it would be nice to have a rio evolution that allow you to edit, click and run anything on your screen.

                                I imagine an editable text toolbar on top of my screen containing things like

                                F1|Mail F2<>Edit Ctrl+F3^Open …

                                Where F1 pipe selected text to a mail program, F2 open selected text in a super simple editor that (simpler than acme and sam), once saved replace the selection, Ctrl+F3 send the selected text to the plumber with the Open command…

                                I guess you get the point…

                                1. 1

                                  it would be nice to have a rio evolution that allow you to edit, click and run anything on your screen.

                                  I feel like rio could be a program that only manages windows and offers a tag window for every window (or only one on top) . The tag window itself could be running a version of acme that doesn’t do window management.

                                  1. 1

                                    Frankly, this is something I have just fantasticated for a while.

                                    The idea is that you should have the ultimate IDE available from boot.

                                    Give a try to Oberon-07 if you want an idea of what I mean: Oberon was actually an inspiration for Acme UI design.

                                    But I’m still working at protocol/kernel level issues in my os, so this is not something I investigated seriously.

                                    1. 2

                                      Yeah I’m familiar with Oberon, though I’ve never actually experimented with it. I’m thinking that a modern acme could just be a graphical window with mouse chording, the text editing could be handled by another program, like the way xi-editor frontends work.

                                  2. 1

                                    Yes, my text editor can do that as well. I can highlight some text, hit the right key (it’s not F2 but some other key my fingers remember) to feed the selection through an arbitrary command and then …

                                    And it’s not even a new text editor, but one I’ve been using for over twenty years.

                            2. 1

                              This is my workflow as well, although I sometimes have the terminal running inside a text editor for ease of navigation.

                              entr is a godsend in this regard, as it offers a language and tooling agnostic way to re-run tests/builds when files change.

                              1. 1

                                I do the same. Do consider using something like screen or tmux, however, for a substantially nicer workflow.

                                1. 1

                                  The last time I used screen in my workflow was when I had to dial up via modem into the school network (through a terminal server). Once ISPs and being part of the Internet became a thing, my use of screen has dropped. Yes, I still create new terminal windows when logging into a remote server.

                                  The only time I use screen these days is if I have to remote into a server and keep a programming running while not logged in. It’s useful, but not a common use case.

                                  1. 1

                                    The last time I used screen in my workflow was when I had to dial up via modem into the school network (through a terminal server). Once ISPs and being part of the Internet became a thing, my use of screen has dropped. Yes, I still create new terminal windows when logging into a remote server.

                                    The only time I use screen these days is if I have to remote into a server and keep a programming running while not logged in. It’s useful, but not a common use case.