1. 6
  1.  

  2. 17

    This is just “Java is a miserable nightmare to program in”, then it just descends into parroting the party line on Unix philosophy with nonsensical statements to back it up. “printf” vs. “System.out.println” is not a great reason.

    1. 25

      Yup. I’ve worked in large Java code bases, large Python code bases, and large C/C++ code bases. The reasons given in this article are imagined nonsense.

      • Remember syntax, subroutines, library features: absolutely no evidence to support this. In all my years I have yet to see even a correlation between the use of IDEs and the inability to remember something about the language. Even if the IDE is helping you out, you should still be reading the code you write. (And if you don’t, then an IDE is not the problem.) This claim is a poor attempt at an insult.
      • Get to know your way around a Project: If anything, IDEs make this simpler and better. I worked in GCC /binutils without tags or a language server for a while and let me just say that without them, finding the declaration or definition with grep is much less efficient.
      • Avoid long IDE startup time / Achive better system performance: Most people I know who use IDEs shut them down or switch projects about once a week, if that. This is just whining.
      • Less Code, Better Readability: Tell this to the GCC and Binutils developers, who almost certainly didn’t use an IDE yet still managed to produce reams of nearly unreadable code. Yet another nonsense claim from the “Unix machismo” way of thinking.

      The other points made in the article are just complaints about Java and have nothing to do with an IDE.

      1. 6

        Avoid long IDE startup time / Achive better system performance: Most people I know who use IDEs shut them down or switch projects about once a week, if that. This is just whining.

        It’s also not even true. In particular tmux and most terminals top out at a few MB/s throughput and stop responding to input when maxed so if you accidentally cat a huge file you might as well take a break. Vim seems to be O(n^5) in line length and drops to seconds per frame if you open a few MB of minified json, and neovim (i.e. vim but a DIY IDE) is noticeably slower at basically everything even before you start adding plugins. Nevermind that the thing actually slowing my PC down is the 5 web browsers we have to run now anyway.

        1. 2

          Vim seems to be O(n^5) in line length and drops to seconds per frame if you open a few MB of minified json

          Obscenely long lines are not a very realistic use pattern. Minified JSON and JS is a rare exception. Vim uses a paging system that deals very well with large files as long as they have reasonable line sizes (this includes compressed/encrypted binary data, which will usually have a newline every 100-200 bytes). I just opened a 3gb binary archive in vim; it performed well and was responsive, and it used only about 10MB of memory.

          1. 3

            A modern $100 SSD can read a few MB in 1 millisecond, $100 of RAM can hold that file in memory 5 million times, and a $150 CPU can memcpy that file in ~100 nanoseconds.

            If they did the absolute dumbest possible implementation, on a bad computer, it would be 4-5 orders of magnitude faster than it is now.

          2. 2

            Oh yes, I didn’t even mention this seemingly ignored fact. I can’t speak for Vim and friends, but Emacs chokes horribly on large files (much less so with M-x find-file-literally) and if there are really long lines, which are not as uncommon as you might think, then good luck to you.

      2. 10

        I’m not a huge fan of IDEs but this article is mostly nonsense.

        This in particular I take exception to:

        Less Code, Better Readability

        Not having Autocomplete / Code Generation guides you naturally to writing more compact and idiomatic Code in the Language of your Choice. It helps you to learn language-specific features and syntactic sugar. Consider

        System.out.println(“hello”);

        printf(“hello”);

        You see that in C, where using an IDE is uncommon, the languge/libraries/frameworks naturally becomes more easily readable and writable.

        I see this as a win for IDEs especially in large projects because the cost of avoiding useless abbreviations is minimal.

        ShoeApi.GetPriceAndFeatures();
        

        is way more readable and explicit than

        Api.GetPrcFeat();
        

        Maybe not the most realistic example but you get what I’m saying and we’ve all seen code like the latter and had no clue what it does without drilling into the method.

        Also since when does having autocomplete equal full-blown IDE?

        1. 4

          The reason the C library and Unix functions have such short names is, in part, because the original C linker only looked at the first 8 characters of symbol names.

          (Likewise, I seem to recall that the original Unix filesystem only allowed 8-character filenames, forcing shell commands to be terse. I may be wrong on this; but most filesystems of that era had really limited names, some only 6 characters, which is why the classic Adventure game was also called ADVENT.)

          1. 3

            I think you might be conflating Unix with MS-DOS. The early Unix file systems allowed 14 character names, while MS-DOS limited filenames of 8 (well, 8 characters for the name, plus 3 for the extension).

            1. 8

              I guess Ken could have spelt creat with an e after all.

            2. 3

              The reason the C library and Unix functions have such short names is, in part, because the original C linker only looked at the first 8 characters of symbol names.

              This was actually part of the first C standard, and it was limited to “6 significant initial characters in an external identifier”. (Look for “2.2.4.1 Translation limits” here.)

              This was almost certainly due to limitations from FORTRAN and PDP-11. PDP-11 assembly language only considered the first 6 characters. (See section 3.2.2, point 3.) FORTRAN (in)famously only used 6 characters to distinguish names. If you wanted interoperability with those systems, which were still dominate in the 80s, then writing everything to fit in 6 characters made sense.

            3. 3
              ShoeApi.GetPriceAndFeatures();
              

              is way more readable and explicit than

              Api.GetPrcFeat();
              

              I see a few independent criteria these comparisons:

              1. The inclusion of the namespace (System. / ShoeApi. / Api vs… not)
              2. Low vs. high context names (ShoeApi vs. Api)
              3. Abbreviated names GetPriceAndFeatures vs GetPrcFeat

              I prefer to elide the namespace if it appears more than a couple times. (X; Y; Z; over HighContextName.X; HighContextName.Y; HighContextName.Z;)

              I prefer high context names, especially when there’s already a namespace. (service.Shoes.Api over service.Shoes.ShoeApi)

              I prefer to not abbreviate. (GetPriceAndFeatures over GetPrcFeat … though both aren’t great.)

              Best (if I must use a Java-like): Api.Fields(Price, Features).Get()

            4. 6

              Drawback: some languages/projects are very unergonomic without an IDE. This is almost always the result of bad language design and/or bad library design.

              I’m no particular fan of IDEs, but if you are designing a language/library with IDEs in mind, it’s obvious that language/library designers are going to consciously or unconsciously make the most of the environment they expect developers will be in when they are designing languages/libraries. Not doing so would be silly, in fact.

              Now, you might not like languages/libraries designed for IDEs, but you cannot simply claim it is bad without reasons in an article with this title - it is the very thing you are supposed to be discussing.

              1. 6

                For example, Apple’s API design guidelines encourage longer names because they’re more readable, especially with the parameter keywords used in Obj-C and Swift. So you get “indexOfSubstring:inRange:” instead of, say, “strstr”. This was of course done with autocomplete in mind, because that means you don’t have to type the long names by hand.

                Likewise, I’m sure LISP coding would be a lot less bearable in an editor that didn’t highlight matching parentheses for you ;-)

              2. 5

                I’ve spent ~2 years trying to do programming without an IDE, just to see if I’ll be a better programmer. I’m considering it a failed experiment.

                • C++: There is simply no substitute for a reliable symbol lookup that understands the context of the code. Ctags are nice until you need to look up where the “get()” method is used. If you code uses C++ templates, it’s a lost cause. This can be fixed with e.g. clangd and LSP-aware editor, but it’s certainly closer to the IDE side this way.

                • Scala: The code is heavily based on implicits, so a good “jump to symbol” functionality is needed as well. As with other languages, IDEs are happily statically analysing the code to find common patterns like .filter().head() is translatable to .find(), if (x.size() == 0) is translatable to if (x.isEmpty()), etc. Code hints can make you learn the language more efficiently, and without IDE the user can run in circles all the time.

                • JVM-based languages: IDE “jump-to-symbol” functions often have decompilation built-in. This means that when jumping from Scala code to an internal Java class, the IDE will not only disassemble, but decompile the Java bytecode if the source is not available. I don’t think that current LSP servers have this functionality (like Metals). This is very useful in cases where the documentation is poor or nonexistant.

                • Skipping the IDE didn’t help me to remember anything. I still need to look up argument order for fread(), google “python make string lowercase”, but that could be also due to language switching.

                • Code discoverability with an IDE is much better than without it. Jump to references, view class hierarchy, show file outline, some of those features I use on daily basis.

                • The “IDE vs non-IDE” argument reminds me of the “real programmers don’t use syntax highlighting” argument. I’ve spent some time thinking about it, but dismissed it entirely, and didn’t make any attempts of verifying it on myself.

                • I did verify however the “DVORAK layout is better”, but its magic didn’t work on me.

                So, I’m classifying the “non-IDE programming is better” to be a hoax.

                That said, I still have a terminal window ready near the IDE, always alt-tab away. It’s much easier to supplement the IDE with the command line tools, than to try to extend a text editor with IDE functionality.

                1. 3

                  The whole dichotomy between an IDE and a text editor is a thing of the past. I tend to use “text editors”, but nowadays live errors & warning, auto-refactoring actions and semantic-aware autocompletion (all just LSP support), syntax highlighting (tree-sitter/LSP) are a basic functionality available almost anywhere. The way I work doesn’t change much when I jump between Kakoune and IntelliJ. The biggest difference is point-and-click-debugging, I guess, which sometimes comes handy in mistake-prone languages like Java, but I don’t have a need for it in Rust.

                  1. 3

                    I personally don’t use IDEs, and not for any of the reasons mentioned in the post. I don’t use them for two reasons:

                    1. I don’t have to learn “yet another editor!” I’ve been programming long enough to remember language-specific IDEs (and to some extent, they still are, see the next point). They were rarely configurable (again, early ones), and they certainly didn’t work like my preferred editor at the time. Things might be better today, but

                    2. I have yet to find one that didn’t crash on me. I have this uncanny ability to crash the darned things. The last one crashed on a simple two-file C program (one C file, one header). Even though it claimed to support “C/C++”, it didn’t. I had valid C code, and yet, it would crash immediately upon loading the project. I suspect I know why [1], but didn’t bother with submitting a bug report for fear of hearing “What? Don’t do that!” because it was really a C++ IDE, not a C IDE.

                    I think I’m just more of a language maven than a tool maven.

                    [1] Because I used ‘class’ as a field name in a structure definition, which is a perfectly cromulent use of ‘class’ in C code.

                    1. 2

                      Avoid long IDE startup time / Achive better system performance

                      From this line alone, I 100% believe the author when they say they’ve used IntelliJ.

                      I’d argue there’s value in being comfortable with a non-IDE text editor, especially a terminal based one like Vim, Nano or Emacs once you add an editor, purely due to convenience. When you need to edit something quickly, or when you need to throw together a quick and dirty program, not needing to totally context switch and pull out a big chonky IDE can be nice and can save time over “load up the IDE, setup things for ${silly project you’ll touch once}, ship these files to a remote server, etc.”

                      For basically every other reason this article lists though… wat?