LISP is 56 years old.
FORTRAN is 57 or so.
C is 42 years old. Lots of languages have tried to replace it, but C is still extremely popular. It must be doing something right.
I say this out of frustration, but it might be a good idea to avoid, for the time being, languages touted as being object oriented. I'm having a really hard time picking up C# because it feels like 90% of it is a complete waste of time. Object oriented programming is probably fantastic when dealing with something gigantic, but it seems to cause more problems than it solves when dealing with small scale things. I would equate it to trying to install hydraulic brakes on a bicycle. It's a kind of needless complexity that makes programming feel like a daunting task that can only be done by the smartest people.
I'll try to demonstrate this by comparing a Perl script I made for printing AutoCAD documents to the way it might be done in C# or Java.
Perl (or C or LISP) reads the way a little kid would describe the problem. It's done in order as a series of vague steps that will be defined later.
-The program starts with a list of variables and a description of each variable.
-The rest of the code is a series of functions and condition statements. There are no classes.
-Functions are lower down in the file, so the script actually starts by using functions that have not yet been written.
Code:
# check if the config folder exists. if not, create it.
use_folder($config_folder);
# try to read the config file. this writes to variable %paths_data
read_paths($paths_file);
# check if the paths in %paths_data are valid
if (check_path($paths_data{autocad_path}) && check_path($paths_data{accoreconsole_path})) {
print "paths are valid\n";
} else {
get_autocad_path();
write_paths($paths_file);
}
# select dsd file (sheet list) to publish
get_dsd_file();
# modify dsd file so it has the date stamp for pdf name
modify_dsd_file();
# create temporary publish script (.scr file)
write_publish_script();
# launch the core console to run the script. delete the temp script when finished:
if (accoreconsole_publish) {
unlink $dsd_new_path;
unlink $publish_script;
}
##########
# Functions are defined lower down
It's very easy to follow what's going on. The first 64 lines of the script say what all of the variables are and what the script does. The rest of the script is
how it does those things, which brings the total up to 324 lines.
To me, this style of programming makes the most sense.
I know the code can be done like this in C# or Java, but that's not the way people teach it. If you read a C# or Java book, the author will try to create a class for everything, almost like they're trying to model the real world or something. It makes programming
feel difficult, and that's not a good thing. Human tend to embrace things that feel easy and avoid things that feel difficult.
A C# or Java book would do the following:
start with the main program, Program.cs
1) Create a Directory class (Directory.cs)
2) Create a File class (File.cs)
3) Create an interface that will be used by Directory and File classes. (IFile.cs)
4) Define the config directory as a Directory object. The path would be an attribute.
5) Define the config file as a File object. The path is an attribute.
6) The "use_folder()" function would be written as a "Use()" method for the Directory class. Or it could be part of a constructor, such as:
Directory myDirectory = new Directory("C:/directory/etc/");
7) We don't want functions dangling out in the middle of nowhere, so we'll make the "read_paths()" function a method as part of a new class called ConfigFile (ConfigFile.cs). The config file is still a file, so we'll set File as the parent class.
8) Undo step 5. Now configFile object is a member of the ConfigFile class, not the File class.
9) I guess we could make autocad_path and accoreconsole_path attributes of the ConfigFile class.
10) Stop and figure out what we're trying to do.
11) We need some kind of method to write the paths data back to the paths file. Maybe make Save() a method of the ConfigFile class. Should we make the method accept variables? I don't know. Who cares. Let's just use some global mutable variable and try to remember what it was.
The problem isn't the language. It's how the language is presented. I could make that same convoluted monstrosity in Perl or Python, but it's less likely to happen because the people teaching those languages don't try to frame things in the most complicated way imaginable.