Comment by switchbak | Hacker News Reader

Comment by switchbak | Hacker News Reader

Parent Full thread

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.

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.

? 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.)

Reply on news.ycombinator.com