Live data from Hacker News

Benefits of Not Using an IDE

alexander-hansen.dev

331–340 of 389 posts

Re: Benefits of Not Using an IDE

#331

Earlier quoted context omitted.

Nah if you ever used a modern IDE from the jetbrains line. In order to even get the IDE working with a project you need to configure it to work. That absolutely necessitates understanding of the details of what's going on. You are literally building automation by using additional tooling. It doesn't build it for you. Also screwing up a git repo, what does that even mean? A bad commit?

If you have a Maven project, IntelliJ will open it and configure itself automatically. The IDE user doesn't need to know anything about Maven build configurations. It just works.

Totally Wrong.

The Maven Project IS the configuration. Intellij is only a shortcut. It let's you access configurations via click rather than via a command line expression.

In the end if you want to create a Maven Project configuration or edit the configuration it's on you to do it. At most intellij will just generate boilerplate for you.

Re: Benefits of Not Using an IDE

#332

Earlier quoted context omitted.

If you have a Maven project, IntelliJ will open it and configure itself automatically. The IDE user doesn't need to know anything about Maven build configurations. It just works.

Totally Wrong. The Maven Project IS the configuration. Intellij is only a shortcut. It let's you access configurations via click rather than via a command line expression. In the end if you want to create a Maven Project configuration or edit the configuration it's on you to do it. At most intellij will just generate boilerplate for you.

[deleted]

Re: Benefits of Not Using an IDE

#333

Earlier quoted context omitted.

If you have a Maven project, IntelliJ will open it and configure itself automatically. The IDE user doesn't need to know anything about Maven build configurations. It just works.

Totally Wrong. The Maven Project IS the configuration. Intellij is only a shortcut. It let's you access configurations via click rather than via a command line expression. In the end if you want to create a Maven Project configuration or edit the configuration it's on you to do it. At most intellij will just generate boilerplate for you.

No that's not how it works. IDEA has its own project files (*.iml, .idea), separate from Maven. We are talking about IDE projects which are separate from Maven.

Re: Benefits of Not Using an IDE

#334

Earlier quoted context omitted.

If you have a Maven project, IntelliJ will open it and configure itself automatically. The IDE user doesn't need to know anything about Maven build configurations. It just works.

Totally Wrong. The Maven Project IS the configuration. Intellij is only a shortcut. It let's you access configurations via click rather than via a command line expression. In the end if you want to create a Maven Project configuration or edit the configuration it's on you to do it. At most intellij will just generate boilerplate for you.

[deleted]

Re: Benefits of Not Using an IDE

#335
post #251

Earlier quoted context omitted.

I'm surprised how many of my colleagues don't use the debugging features of their IDE. Being able to step through code line by line and see all the variables states at any time and evaluate arbitrary expressions given those states seems far superior to print/console based guesstimation. However, somehow my colleagues still do great work!

So far as I can tell from having worked with lots of people with lots of different preferences, there is basically no correlation between preferences in debugging approaches and ability/productivity. I do however really wish the world made it easier to help turn both state introspection via interactive debugger and state introspection via printf shotgun into structured trace-level logging that could be shared and/or…

Yes this. Distributed tracing is making these concepts more popular but in many cases it requires manual instrumentation of every function call and state one wants to track. I would love to see more auto-instrumentation but seems this should be implemented at the interpreter or compiler level.

Re: Benefits of Not Using an IDE

#336

Earlier quoted context omitted.

Totally Wrong. The Maven Project IS the configuration. Intellij is only a shortcut. It let's you access configurations via click rather than via a command line expression. In the end if you want to create a Maven Project configuration or edit the configuration it's on you to do it. At most intellij will just generate boilerplate for you.

No that's not how it works. IDEA has its own project files (*.iml, .idea), separate from Maven. We are talking about IDE projects which are separate from Maven.

Yes that's configuration for the IDE. But the project itself is configured off of Maven, the project files for the IDE are ADDITIONAL settings for the IDE itself.

For example in CLion you can't create a new target from the IDE, you have to edit the cmake file.

Re: Benefits of Not Using an IDE

#337

Earlier quoted context omitted.

The good editors for programmers, since ancient times, for example already in the BRIEF editor for MS-DOS, before 1990, provide means to attach arbitrary CLI commands or scripts to menus or keyboard shortcuts. Therefore, if you want you can invoke from inside the editor any commands needed for project management or for compiling/linking/running/debugging. So in the end you are right that a powerful editor can do what…

Have you published this makefile somewhere? I’d love to take a look at it.

It is not published, but there is not really much about it, except exploiting most features provided by gmake.

For easy maintenance, the universal makefile is split into 4 files that are completely universal + 1 makefile with extra definitions per each combination of operating system and CPU type that might be a target for compilation.

The extra files for specific compilation targets, e.g. skylake-linux-gnu, armv7e-m4-none-eabi, i686-cygwin and so on, contain definitions for the names of all the tools that might be used, e.g. compilers for various programming languages, linking commands, librarian commands, binary file modification commands (e.g. objcopy), default locations for library files, default locations for include files, default values for compilation flags.

The 4 completely universal files do not contain directly any command name or command flags or any file name or any directory name. They contain only variable names whose values are either defined in the operating system/CPU specific makefile or whose values are determined by the make command by scanning the project and by transforming the found files, e.g. by replacing the file name extensions.

The 4 completely universal files are:

1. A file for the top directory of a complex project, which descends recursively in all subdirectories and runs there the given make command, if a Makefile exists in the subdirectory

2. A file with make targets. Examples of make targets:

clean:

$(RM) $(RMFLAGS) $(MAP) $(BIN) $(IMPLIB) $(EXE) $(LIB) $(WEXE) $(DLIB)

$(RM) $(RMFLAGS) $(OBJS) $(OBJS:.o=.d) $(OBJS:.o=.lst)

and

all : $(EXE) $(LIB) $(WEXE) $(DLIB)

The 4 variables above are the files to be built, respectively CLI executables, static libraries, GUI executables and dynamic libraries.

As I have said everything must be expressed using variables that will be defined elsewhere.

3. A file with make rules, for how to build any kind of file that might be encountered. Examples of rules:

%.o: %.c

$(CC) $(CFLAGS) $(DEFINES) $(INCLUDES) -o $@ -c $%.s: %.cpp

$(CXX) $(CXXFLAGS) $(DEFINES) $(INCLUDES) -o $@ -S $%.d: %.cpp

$(CXX) $(CXXFLAGS) $(DEFINES) $(INCLUDES) -MD -o $(@:.d=.o) -c $4. A file with definitions, which is the most important in simplifying the makefiles needed for any new project, which are typically almost empty, because they do not need any other line besides including the universal makefile, even if I usually add a definition with a list of source directories, in order to separate the place where the project is built from the place where the source files are stored and possibly some options, e.g. building a debug version instead of a release version, or building for a cross-compilation target.

Example how to determine the directories with source files:

ifeq "$(strip $(SOURCE_DIRS))" ""

SOURCE_DIRS := .

endif

ifeq "$(strip $(PREFIX_DIR))" ""

VPATH := $(SOURCE_DIRS)

else

VPATH := $(addprefix $(PREFIX_DIR)/, $(SOURCE_DIRS))

endif

Example of how to scan the source directories for source files written in a certain programming language:

CPP_FILES := $(notdir $(wildcard $(addsuffix /*.cpp, $(VPATH))))

The list for every kind of source files is stored in a corresponding variable like above.

For the source files that are compiled to object files, the list of object files that must be made is computed so:

OBJS := $(CPP_FILES:.cpp=.o) $(C_FILES:.c=.o) $(SS_FILES:.S=.o) $(S_FILES:.s=.o) $(O_FILES)

I use many more kinds of source files, so the OBJS above is just a shortened example.

The operating system/CPU type specific makefile includes the 3 universal files with targets, rules and definitions and it also includes the automatically generated dependencies:

include $(OBJS:.o=.d)

so later only the specific makefile needs to be included, depending on the compilation target.

There are many more details, but these are the general principles. They are intended to make me write as little as possible in the Makefile for a new project.

If I do not define in the Makefile from the project directory what shall be built with "make all", then either an executable is built, having the same name as the Makefile directory, or another kind of file is built, if the directory has a special suffix, e.g. a static library for a directory ending in "_lib".

When I add, delete, move or rename source files, I do not have to do anything for project management, except doing a "make clean" before that, because the next "make" will update the lists of source files.

Re: Benefits of Not Using an IDE

#338

Earlier quoted context omitted.

No that's not how it works. IDEA has its own project files (*.iml, .idea), separate from Maven. We are talking about IDE projects which are separate from Maven.

Yes that's configuration for the IDE. But the project itself is configured off of Maven, the project files for the IDE are ADDITIONAL settings for the IDE itself. For example in CLion you can't create a new target from the IDE, you have to edit the cmake file.

Your wording is not precise

> In order to even get the IDE working with a project you need to configure it to work.

Meaning you already have a Maven/SBT/Gradle project and need to get the IDE to work with it.

Re: Benefits of Not Using an IDE

#339
“IDEs considered harmful”. That's exactly the thesis of Nicholas Carr's book, “The Glass Cage”. He claims the more we employ cognitive-enhancing tools like IDEs to help us perform tasks that require mental effort, the less engaged we become, the less creative, and the less effort we're willing to apply in tackling other kinds of mental tasks. In short, “flow” stops when we disengage and let automation to do the job for us.

https://www.amazon.com/gp/product/B00J9PQXOE/ref=dbs_a_def_a...

Post reply on HN