7 ms·

I experienced a crystal clear example of this about 15 years ago. I developed a prototype of perl script that read data from one folder, filtered and enhanced

I experienced a crystal clear example of this about 15 years ago. I developed a prototype of perl script that read data from one folder, filtered and enhanced it, and wrote it out to another folder, where it was picked up by another process. The script was configured by another perl file that contained the paths to read and write from. The initial (pre-production) deployment had the two folders adjacent, so the config script looked something like $input_folder = "/some/annoyingly/long/path/my-cool-project/input/" $output_folder = "/some/annoyingly/long/path/my-cool-project/output/" At some point the script was handed off to some other dev who looked at those paths and apparently thought "that's not DRY!", and changed the code so that the config file just had $project_folder = "/some/annoyingly/long/path/my-cool-project/" and actually append the "input" and "output" in code when needed (fairly elegantly leveraging some existing keys that already defined those two strings). The problem was that when I developed the script the actual consumer hadn't been finalized, so that output folder path was just a placeholder. When it comes time to deploy we get the actual path which is now some NFS thing like /mnt/other-services-host/other-service/input/ At this point I naively go to the config to update my $output_folder variable and discover the code changes made by the other dev, which have made it impossible to separate the two folders, and because of the "elegant reuse of existing keys" made it a huge pain to even change the code back, since the assumption that the last segment of the path had to match the intended use was deeply baked in. At this point I think I just started swearing for a week.

yyx 8y ago
That's why you make it as parameter
- perl4ever 8y ago
  One might contemplate the question of why people use config files in some cases and command-line parameters in others. Having a section for constants at the beginning of a script resembles a config file to some extent.
  - TeMPOraL 8y ago
    Implicit assumption that other people's code is off-limits? Most software on my machine has probably arrived from apt-get at some point or another. Even if it's all Perl scripts, I'm not going to overwrite them directly, only to have my changes either removed on update, or blowing up the package manager's consistency checksums, or [insert random reason I can't conceive, because I'm not familiar with internals of apt]. So it's either config files, command line, environmental variables, or I'm going to build a wrapper that bends installed software to my will.
DerSaidin 8y ago
Too much abstraction?... Or not enough abstraction? $project_folder = "/whatever"; $input_folder = $project_folder . "/input"; $output_folder = $project_folder . "/output";
- aserafini 8y ago
  This does not solve the problem. The input and output folders had different roots in the production app.
  - dwaltrip 8y ago
    However, that abstraction is very localized and thus easy to remove (once the new understanding has been gained), so I'd say it is better.
- im3w1l 8y ago
  Yeah that looks nice. An overabstracted example would be $project_folder = "/whatever"; $in = "in"; $out = "out"; $suffix = "put"; $directory_separator = "/"; $input_folder = $project_folder . $directory_separator . $in . $suffix; $output_folder = $project_folder . $directory_separator . $out . $suffix;
  - MattHeard 8y ago
    $in = "in"; $out = "out"; Those are not really abstractions, just extracted variables. An abstraction would change the concept language. $suffix = "put"; This is also not an abstraction, as the language of the term "suffix" comes from its role in string concatenation, which is the same as the role of the original string literal. It doesn't change the "level of abstraction". This isn't an over-abstraction, it's an over-extraction. Each abstraction should be non-trivial. $project_folder = "/whatever"; is a good abstraction. Looking at the string literal "/whatever", I cannot determine it's "role", but $project_folder is a good name and changes the concept language from being about string concatenation or arbitrary names into a concept language about projects and folders.
- xorcist 8y ago

yyx 8y ago

That's why you make it as parameter

perl4ever 8y ago
One might contemplate the question of why people use config files in some cases and command-line parameters in others. Having a section for constants at the beginning of a script resembles a config file to some extent.
- TeMPOraL 8y ago
  Implicit assumption that other people's code is off-limits? Most software on my machine has probably arrived from apt-get at some point or another. Even if it's all Perl scripts, I'm not going to overwrite them directly, only to have my changes either removed on update, or blowing up the package manager's consistency checksums, or [insert random reason I can't conceive, because I'm not familiar with internals of apt]. So it's either config files, command line, environmental variables, or I'm going to build a wrapper that bends installed software to my will.

DerSaidin 8y ago

Too much abstraction?... Or not enough abstraction? $project_folder = "/whatever"; $input_folder = $project_folder . "/input"; $output_folder = $project_folder . "/output";

aserafini 8y ago
This does not solve the problem. The input and output folders had different roots in the production app.
- dwaltrip 8y ago
  However, that abstraction is very localized and thus easy to remove (once the new understanding has been gained), so I'd say it is better.
im3w1l 8y ago
Yeah that looks nice. An overabstracted example would be $project_folder = "/whatever"; $in = "in"; $out = "out"; $suffix = "put"; $directory_separator = "/"; $input_folder = $project_folder . $directory_separator . $in . $suffix; $output_folder = $project_folder . $directory_separator . $out . $suffix;
- MattHeard 8y ago
  $in = "in"; $out = "out"; Those are not really abstractions, just extracted variables. An abstraction would change the concept language. $suffix = "put"; This is also not an abstraction, as the language of the term "suffix" comes from its role in string concatenation, which is the same as the role of the original string literal. It doesn't change the "level of abstraction". This isn't an over-abstraction, it's an over-extraction. Each abstraction should be non-trivial. $project_folder = "/whatever"; is a good abstraction. Looking at the string literal "/whatever", I cannot determine it's "role", but $project_folder is a good name and changes the concept language from being about string concatenation or arbitrary names into a concept language about projects and folders.
xorcist 8y ago