Comment by dan_mctree | Hacker News Reader

Comment by dan_mctree | Hacker News Reader

Parent Full thread

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".

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

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.

Reply on news.ycombinator.com