4 ms·

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

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.

gowld 9y ago
? Ant and Maven work fine in my IDE
- shakna 9y ago
  > This was a real problem back in the earlier Java days before Ant/Maven/etc came around. (Emphasis mine.)
dan_mctree 9y ago
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".
- sanderjd 9y ago
  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.
- kd5bjo 9y ago
  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.
  - TimJYoung 9y ago
    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).
j2kun 9y ago
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.

gowld 9y ago

? Ant and Maven work fine in my IDE

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

dan_mctree 9y ago

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

sanderjd 9y ago
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.
kd5bjo 9y ago
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.
- TimJYoung 9y ago
  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).

j2kun 9y ago

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.