Hacker News Reader

Surprisingly I think I'm the first to disagree.

I find a modern IDE comes with so much implied mental baggage that new users can get completely overwhelmed. Sure, languages which require complex build environments almost demand one, but in simpler environments it can be a lot easier to reduce the cognitive load in a simplified environment.

One can do a lot of programming and learning with just a simple editor (Nano?) and a Python-like environment (repl, interpreter). With quality online notebook-style environments, we can now accomplish an outrageous amount with very little time or cognitive overhead devoted to build tooling.

As professionals, we ought to be familiar with the underpinnings of our tools though. It can be really painful trying to work with a colleague who's afraid of getting low level to really understand their build issues. I've worked with people who actually become visually agitated when I open up a command line.

What's worse (I see less of this these days) are those who are so coupled to their IDEs that they don't use proper build tools - limiting reproducability, CI integration, etc. This was a real problem back in the earlier Java days before Ant/Maven/etc came around.

No need to shun an IDE - I certainly don't, but one needs to understand how it works otherwise you risk having incorrect (overly simplified) mental models about how your programs are built and run.

? Ant and Maven work fine in my IDE

> This was a real problem back in the earlier Java days before Ant/Maven/etc came around. (Emphasis mine.)

For me it's the opposite. A modern IDE is significantly easier to understand, with far less mental baggage than some hacked together combination of several CLI based tools. The mental drain of clicking some nice green play arrow on screen when you want to execute code is non-existent. The baggage of remembering which tool does what, what weird flag you have to keep adding to one of the commands you need, what keyboard shortcut you needed again to exit your CLI based text editor, all of that takes far more baggage for me. Especially when you have 10 different setups like it, and may not return to some of them for months.

And even if you do somehow remember how all of your CLI tools fit together, you're still missing out on an incredible amount of power and clarity that IDEs provide. A CLI just doesn't have the ability to show information nearly as well as a GUI, it doesn't even come close in terms of the amount of bits worth of information you can show simultaneously, nor in its ability to use positioning and formatting to clarify what's important and related. Add that GUIs provide constant in your face hints that tell you what your options are, and it's no wonder almost everyone finds them significantly more pleasant to use. You don't have to remember anything, it shows you.

Yes, people end up developing bad habits and will run into some problems later. But these issues aren't as significant as people giving up early because of learning curves that are too steep on software which is only vaguely connected to what they actually want to do. "I want to build an app" is what drives people, not "I want to learn all the flags for javac".

The problem is figuring out what to do when the little green play arrow doesn't do anything or is grayed out for whatever reason. Fixing that probably requires a bit of knowledge of both the language toolchain and the particular IDE. Typing "python" at a command line and getting a prompt can certainly seem easier.

CLI tools are all about codeveloping the build environment with the project. Instead of you trying to remember the weird flags, write a one-line shell script and save it with the project.

For example, my current side project is built on C+SQLite. The larger chunks of SQL are plain text files so that I don't have to worry about C string escaping. Instead of trying to read them at runtime, I have the build process wrap them in a .o file that gets linked into the executable.

This is relatively simple because it's just a slight variant on what's already happening (.sql files are "compiled" with objcopy instead of gcc), but I've utterly failed whenever I've tried to do something similar in an IDE-based project.

On the other hand, the standard build process is generic enough these days that most projects don't need to do this sort of customization. For those projects, being locked into the IDE's process isn't really a drawback and you may as well take advantage of the benefits it provides.

Just to give you an idea of how you would do that in Delphi (even in 1996):

1) Drop an instance of your database-specific query class (or a generic database API query class, such as ODBC, ADO, etc.) on a form or data module.

2) Click on the property editor button next to the SQL property for the class instance in the object inspector.

3) Input your SQL in the provided window (or load/save to/from a file, whatever the property editor allows for).

4) Compile your application.

That's it. The SQL is now automatically included as a resource in your executable and is available to you at runtime as if it were assigned at application startup. And this isn't just limited to SQL - you can do this with any text or binary file. It's all only limited by the imagination of the developer of the component(s) that you're using in the IDE.

Visual Studio has always been a bit more obtuse in how it handles datasets/databases, so it's probably more of an example of how not to do something like this in an IDE.

The point is that a beginner can do the above, whereas I'm not sure that a beginner would even know where to begin when it comes to implementing what you've done (which is very well done, putting all of this aside).

I'm glad that at least one IDE gets this particular case right, but I think I missed my broader point.

As a programmer, my job is to produce a set of instructions that a computer can understand. The Unix shell is quirkier than most, but it is a real programming language that I can bring all of my profession's skills to bear on. IDEs, on the other hand, are opaque boxes that work great until you need something they didn't anticipate.

I'll readily admit that my needs are no longer those of a beginner, but my learning path was a pretty steady climb of copy/pasting boilerplate, to making a few small changes, to just starting with an empty file and writing everything from scratch.

I worry[1] that, by hiding complexity from beginners, we may be hindering eventual mastery in the name of making it easy to start learning. Are modern intermediate-level developers asking questions like:

- I've been told to always do X; what happens if I don't? - This thing I usually ignore seems vaguely related to my current problem; what does it actually do?

[1] Without any real foundation or evidence

My first few years of programming were all in Java/Eclipse, and I had an irrational fear of the java/javac CLI compile & run commands. I was completely incapable of modifying build and run scripts (which were customized by one guy at my company), and it was a huge gap in my knowledge. So I have lived this firsthand and can see the value in retrospect.

That being said, I did get a LOT done with the pure IDE (three years of school programming and a year of part time work). So there's something to be said for both sides.

> It's ridiculous to expect newcomers to a language and/or programming in general to slog through a 20 or 30-step environment setup process

Modern IDEs often require an hour long install, and then you turn them on and are faced with 10,000 buttons and 50 windows, they aren't simple either.

I have had good success with making beginners people sit through a 30 minute dev environment set up process, in video form. No complaints, everyone got it working, on linux, mac, and windows. I used VS Code + the Go language plugin. Once set up, you have a pretty simple IDE-like environment.

I do miss the days when every dos PC just shipped with QBasic, or when you could get a simple, quick loading IDE like TurboC++

VS Code is modern ide. And I would really like to know which IDE takes an hour long install. Because I tried multiple on windows and they all required download, double click and that was it.

Visual Studio, Jetbrains, if you happen not to have a fast internet connection and SSD can take a long time.

Installing Android Studio over a slow connection was a real PITA.

Having to wait an hour for a download/install to complete is completely different from requiring an hour of browsing stackoverflow to figure out why the CLI install instructions given aren't working on your device.

You're not exactly wrong, but are we not still comparing to "turn computer on, get BASIC prompt" (C64), or "turn computer on, type 'qbasic', hit enter"?

Visual Studio (proper) has famously long installation times. VS2017 provided a significant installation time decrease but was still on the order of 30 minutes for my company-issued MBP.

In 2015, VS took me multiple hours to install and often minutes to open. The most unpleasant piece of software I have ever used. I hear it's better now.

Installing visual studio 2017 in a windows VM on a ryzen 1600 with an ssd and 16GB ddr4 and a fast internet connection took 3 hours, just did it a few days ago

VS Code is a modern extensible programmers editor; with appropriate extensions, it approximates an IDE, but it's not an IDE like Visual Studio proper, Eclipse, etc.

Now, most actual IDEs don't take long to install either, but VS takes approximately forever.

> Shun IDEs

Well, I don't think anybody is "shunning" IDEs just to be difficult; it's just really, really hard to describe something in the context of an IDE. For one thing, IDEs are (obviously) graphical, so you have to include a screenshot if you want to refer to something. Worse, IDEs change things around a lot (sometimes for no particular reason). Then of course, there are no standards in this area - in Java you have Eclipse and IntelliJ, so if you want to describe something in terms of an IDE you either pick both and double the explanations, or you pick one and freeze out the others... or you just do everything on the command-line which is unambiguous. And don't forget, eventually you're going to have to get out of the IDE comfort zone if you want to interface with a continuous integration system.

Commandline instructions fail as often as IDE based instructions do. Changes in different versions, changes in the environment, different ways of trying to use the software, different ways projects were set up; all of these and many other reasons cause plenty of issues with commandline based instructions. It's never "just do everything on the command-line", it's "it just spewed out an essay of errors on step 2, and google is silent"

It's not really that hard, though. Almost everything you see in an IDE is just a pretty version of something in a text file somewhere. IDE's don't get rid of project files, source files, object files, etc. They just simply manage the complexity in a way that keeps what you need at your fingertips.

> It's ridiculous to expect newcomers to a language and/or programming in general to slog through a 20 or 30-step environment setup process.

It's ridiculous for anyone really. If you're not using something outside of the standard libraries, it's ludicrous to expect someone to slog through the manual setup process when they can double click an IDE icon and be ready to program in under a minute.

Not to mention the fact that a lot of those setup guides are for specific OSes and the author always seems to leave that part out. So you get to step fifteen and get a weird makefile error only to find out that that particular library is for another OS with no alternative for your own. This forces you to restart at square one with more potential added steps (eg virtual machine setup, OS setup, etc).

IDEs are not magic, they don't make OS-specific libraries just work on other OSs. And they're not required to automate stuff either.

I do Java programming by day, and I still find the IDE to be a pain in the ass. It offers me a lot of power (enough that I still use it for all my Java code), but the configuration is so opaque. It's a GUI, but what a confusing, complicated GUI.

In contrast, opening a repl in python/node is super easy, and it was super easy even when I was a beginner.

Building a GUI like you said would be hard, (though I did a very simple tkinter gui in my first year), but I think that even for a beginner, opening a repl and starting to muck around is easier without the IDE in the way.

Indeed. There's no way I would've learned how to program at such an early age if the process had been any more complicated than "install Turbo Turtle." (And later, HyperCard, THINK Pascal, THINK C, and finally CodeWarrior.) It wasn't until I had basic command of a few different languages that I was thrust into the world of UNIX, emacs, Perl, CPAN, and so on. By that time I was able to handle it, but if that had been my first go of it, I'd have run for the hills and never looked back.

Jesus christ, this. I was doing free online course recently and guess what the forum was full of: self proclaimed geniuses that discouraged beginners from using IDE "notepad is enough". In java mind you, just about the worst language to write in notepad.

Of course they struggled with homework.

Yes, I remember people who would say that. I guess they felt it made them look smart.

Delphi was WAY ahead of it's time. I agree with your point. Installing the IDE also installs just about any library you would want, even TCP/IP socket libraries in 1996.

It's literally:

  1. Install
  2. Wait forever (CDs are slow)
  3. Run it
  4. Code, compile and run.

Yeah if anything it's people moving away from IDEs that's making life much more difficult. The complicated part of an install is rarely ever just downloading some software, clicking the executable and then 'next' a few times.

The hard part is docker throwing out nonsensical error messages into your console, offering 3 equally illegible possible solutions, which after 2 hours of googling and attempts turn out to be wrong, because all you needed was a reboot to get to the next error (which ends up being caused because of one of the 3 attempts to fix the earlier problem).

Yeah sure, with an IDE you might not grasp what really happened, but do you really with the 15 step install instructions? Both GUIs and CLIs only ever show the information that the programmer decided to output anyway, and GUIs are actually much better at showing legible output due to all the extra space, formatting options, etc. So what is it that people think makes a CLI somehow grasp what's happening better? The fact you just copy pasted some command with 3 flags?

> The hard part is docker throwing out nonsensical error messages into your console, offering 3 equally illegible possible solutions, which after 2 hours of googling and attempts turn out to be wrong, because all you needed was a reboot to get to the next error (which ends up being caused because of one of the 3 attempts to fix the earlier problem).

Docker is a CLI program written by GUI programmers — it's a whole new level of terrible. It's certainly not a stain upon the CLI escutcheon.

>The hard part is docker throwing out nonsensical error messages into your console, offering 3 equally illegible possible solutions, which after 2 hours of googling and attempts turn out to be wrong, because all you needed was a reboot to get to the next error (which ends up being caused because of one of the 3 attempts to fix the earlier problem).

Are you talking about kernel updates breaking docker until reboot? Yes that's annoying but you have to reboot anyway.

Visual Basic was this for many people. These days the Community edition of Visual Studio with C# comes close, with a combination of drawable GUIs, code generation, and generous autocomplete.