3 ms·

Programming is enormously more complicated today because modern development environments aren't designed for simplicity. When I first started programming all o

Programming is enormously more complicated today because modern development environments aren't designed for simplicity. When I first started programming all of my tools had a simple workflow: * Write a single text file * run a single command to build (cc thing.c) * Run the resulting file as a standalone command People learning to program are often new in general. They're figuring out their text editors. Figuring out how to run programs. Figuring out so many basic things seasoned developers take for granted. I became quite fluent in C, writing many, many useful programs with just a single text file. By the time I had a need to learn about linking multiple files in large projects I was already fluent and comfortable with the language basics. Contrast this with modern environments: I need to learn whole sets of tools for managing development environments (venv, bundle, cargo, etc etc etc). These development harnesses all change rapidly and I am constantly googling various sets of commands and starter configs to get things running. These are all things that a seasoned developer will be constantly dealing with on a complex project, but it seems like little effort has been put into creating basic defaults to simplify things for beginners.

_wldu 4y ago
I agree 100%. Massive frameworks with massive complexity. I don't enjoy them at all. That's one reason I like Go. It's very modern, but I can still use vim and a simple Makefile to control it.
rmah 4y ago
I started programming professionally in the late 1980's (almost a half century ago :-)... and we had IDE's, UI builders, databases, "resource managers", etc. One the UI side, we had to deal with windows, layouts, menus, event loops, controllers, graphs, etc, etc, etc. Pretty much everything you have to deal with today. It was, IMO, just as complicated (if in a somewhat different way). Yes, most commercial software packages were written in C. They certainly weren't in one file. They were large systems that took hundreds, sometimes thousands of files and 100k's to millions of lines of code. If anything, we had to write more code to do things because pre-packaged libraries weren't as comprehensive back then. I still remember waiting hours and hours for our application to build. And the old timers told us that that was blazingly fast, lol. I would agree with a previous poster that there are many more choices today. And I guess if you suffer from a fear of making the wrong choice, that is a problem. But the other side of that is that literally thousands and thousands of examples and even robust code libraries are now available for free that you can drop in and use. That is a HUGE plus.
- throwaway09223 4y ago
  Yes we had those things but my point is that they were optional and not commonly used except in large system projects. We didn't throw all that complexity at people learning the basics. The interface for beginners scaled all the way down to a very basic single text file, and most beginners would program for months or even years without using those things. It wasn't necessary to teach these tools in school - you could complete an entire degree writing single-file C programs without ever using an IDE. Many utilities were distributed as a .c file and a Makefile and that's it (before the rise of autoconf)
  - thewebcount 4y ago
    I agree with most of what you’re saying, but for me, the IDE was waaaaay easier than dealing with a Makefile (yet another programming language that has nothing to do with my goal), or worse, entering random hard-to-remember commands and options on the command line. Even if my program was a single file, it was usually just Cmd-R to build and run. No need to memorize that I needed to add “-l math” if I was doing anything with math functions, or whatever.
    - throwaway09223 4y ago
      Makefiles for basic projects are typically just two to five lines long. It's really different than a large project system, or the absolutely crazy things that autoconf generates. all: cc myprogram.c clean: rm -f myprogram.o myprogram They're extremely simple in simple scenarios. It's just a simple format for writing down the commands you run while working.
falcolas 4y ago
I agree with all of this, and then some. My recent lament was how one tool in my tool chain for a project managed by someone else in my company which, despite being in the same language, required a specific variable to be set in my environment. Back in my day, being on the path was sufficient. And it is for all the other Java projects. I spent too long sorting that one out.
NoraCodes 4y ago
I mean, invoking rustc on a single rust file is no harder than invoking gcc on a single file. cargo adds other features, as do make, cmake, etc for c.
kaeshiwaza 4y ago
I still work like that 30 years after, thanks to Go... I would not like beginning today !
ducharmdev 4y ago
If you have a base familiarity with the command line, I think many build tools do have great basic defaults, e.g. `dotnet run`, `cargo run`, `npm run dev`, etc. Vite is another example of good defaults in frontend dev; it allows you to sidestep a lot of the difficulty one may run into with webpack. But I think you're right in many ways though. For seasoned devs, cli tools give a lot of flexibility and allow dev tasks to be automated in pipelines more easily, but it requires one to read documentation or use the help subcommand to discover what else you can do. Which is not a big deal when you are experienced, but I definitely remember struggling early on with things like that when I was self-teaching how to program.
RunSet 4y ago
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

_wldu 4y ago

I agree 100%. Massive frameworks with massive complexity. I don't enjoy them at all. That's one reason I like Go. It's very modern, but I can still use vim and a simple Makefile to control it.

rmah 4y ago

I started programming professionally in the late 1980's (almost a half century ago :-)... and we had IDE's, UI builders, databases, "resource managers", etc. One the UI side, we had to deal with windows, layouts, menus, event loops, controllers, graphs, etc, etc, etc. Pretty much everything you have to deal with today. It was, IMO, just as complicated (if in a somewhat different way). Yes, most commercial software packages were written in C. They certainly weren't in one file. They were large systems that took hundreds, sometimes thousands of files and 100k's to millions of lines of code. If anything, we had to write more code to do things because pre-packaged libraries weren't as comprehensive back then. I still remember waiting hours and hours for our application to build. And the old timers told us that that was blazingly fast, lol. I would agree with a previous poster that there are many more choices today. And I guess if you suffer from a fear of making the wrong choice, that is a problem. But the other side of that is that literally thousands and thousands of examples and even robust code libraries are now available for free that you can drop in and use. That is a HUGE plus.

throwaway09223 4y ago
Yes we had those things but my point is that they were optional and not commonly used except in large system projects. We didn't throw all that complexity at people learning the basics. The interface for beginners scaled all the way down to a very basic single text file, and most beginners would program for months or even years without using those things. It wasn't necessary to teach these tools in school - you could complete an entire degree writing single-file C programs without ever using an IDE. Many utilities were distributed as a .c file and a Makefile and that's it (before the rise of autoconf)
- thewebcount 4y ago
  I agree with most of what you’re saying, but for me, the IDE was waaaaay easier than dealing with a Makefile (yet another programming language that has nothing to do with my goal), or worse, entering random hard-to-remember commands and options on the command line. Even if my program was a single file, it was usually just Cmd-R to build and run. No need to memorize that I needed to add “-l math” if I was doing anything with math functions, or whatever.
  - throwaway09223 4y ago
    Makefiles for basic projects are typically just two to five lines long. It's really different than a large project system, or the absolutely crazy things that autoconf generates. all: cc myprogram.c clean: rm -f myprogram.o myprogram They're extremely simple in simple scenarios. It's just a simple format for writing down the commands you run while working.

falcolas 4y ago

I agree with all of this, and then some. My recent lament was how one tool in my tool chain for a project managed by someone else in my company which, despite being in the same language, required a specific variable to be set in my environment. Back in my day, being on the path was sufficient. And it is for all the other Java projects. I spent too long sorting that one out.

NoraCodes 4y ago

I mean, invoking rustc on a single rust file is no harder than invoking gcc on a single file. cargo adds other features, as do make, cmake, etc for c.

kaeshiwaza 4y ago

I still work like that 30 years after, thanks to Go... I would not like beginning today !

ducharmdev 4y ago

If you have a base familiarity with the command line, I think many build tools do have great basic defaults, e.g. `dotnet run`, `cargo run`, `npm run dev`, etc. Vite is another example of good defaults in frontend dev; it allows you to sidestep a lot of the difficulty one may run into with webpack. But I think you're right in many ways though. For seasoned devs, cli tools give a lot of flexibility and allow dev tasks to be automated in pipelines more easily, but it requires one to read documentation or use the help subcommand to discover what else you can do. Which is not a big deal when you are experienced, but I definitely remember struggling early on with things like that when I was self-teaching how to program.

RunSet 4y ago

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”