7 ms·

25 years ago pretty much every program had a GUI to do the configuration. With help texts. On Windows, programs then either saved stuff into an ini file or the

25 years ago pretty much every program had a GUI to do the configuration. With help texts. On Windows, programs then either saved stuff into an ini file or the windows registry, both you could also edit manually. Today we have a programming language coming as a 87 MB binary to create config files. And to run that programming language you need to manually crate a ... config file. So what we are missing now is a 500GB framework that can write the config file for the programming language that is writing a config file for the actual program I wish to use. I am sorry, but very clearly a huge chunk of today's "developers" really are in the business of creating problems.

afavour 3y ago
That strikes me as a very uncurious perspective. There’s absolutely nothing that could be improved about configuration files? An 87MB binary feels like a very arbitrary measure of worthiness.
- Aeolun 3y ago
  I mean, there is something to be said against using the equivalent of 87 novels worth of text to produce a note’s worth of configuration.
- Fischgericht 3y ago
  ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS. And again: If your config files are so complex, how about just creating a TUI/GUI so the user can configure your program in an accessible fashion? Anyway, yes, there is something that can be improved: Create a standard instead of adding another layer of complexity for something that should be very simple in the first place. Yes, binary size may feel arbitrary, but it often gives a hint about the hammer's size.
  - ivlad 3y ago
    > TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS. INI is hard to parse because without quotes the parser would not know whether it’s a “True” as a string or True as Boolean value. Formal parser that can be included into a program as a library and would reliably generate internal config representation (e.g., read config file into an object in application memory that will be used to modify the behaviour) is a good thing and TOML helps with that while INI does not.
    - mixmastamyk 3y ago
      Schemas are often better than syntax typing. In other words the program decides what the type is, not the file.
      - Silphendio 3y ago
        If the schema allows union types, I don't want to deal with unquoted strings.
        mixmastamyk 3y ago
        You don’t deal with syntax period. Union types are not desirable with configuration with the exception of |null perhaps, which should receive a default.
    - Fischgericht 3y ago
      Yes, agreed. On the other hand, there are quite a few people using Javascript, a language where this distinction also isn't really done in a clean way. If you would de-serialize an ini-file into Objects in memory you would typically have meta-data about your object (RTTI/Reflection for compiled languages, given for scripting languages). But yes, INI isn't without flaws. Parsers typically will need to accept everything from "true", "True", True, true, 1, "1" for boolean fields.
  - 3y ago
n42 3y ago
Yes, the windows registry, the peak of our craft. No need to innovate, this one’s solved, wrap it up and move on Try taking more time to consider the problems you don’t have that others do, instead of writing anything off that doesn’t make sense to you (and simultaneously gatekeeping an entire industry)
- sigzero 3y ago
  I am taking your comment as a joke because the Windows Registry is a joke.
  - fallensatan 3y ago
    I think they are being sarcastic about windows registry.
- Fischgericht 3y ago
  Creating complex layers upon layers just to "solve" a very simple problem is not innovation. It's shittification.
  - cqqxo4zV46cp 3y ago
    Misappropriating a trendy word to use as a descriptor for anything you don’t like. This is how someone speaks immediately before taking a look in the mirror and realising that they sound like their parents. You are not the be-all end-all and your drive-by analysis of a technology is going to be biased by its suitability for what you do day-to-day. No amount of experience justifies your attitude.
    - Fischgericht 3y ago
      I am sorry if the wording of my opinion has offended you. My parents most likely would have complained that they'd need 58 floppy disks to run this programming language. :)
      - 3y ago
ivlad 3y ago
25 years ago admin would be responsible for one server, that they would setup and then never touch until (and sometimes after) someone hacked it. Now people are responsible for thousands of containers, and GUI simply does not scale. And the configuration of those containers is domain-specific and/or varies enough so that you cannot write a single config file and copy it over. This is why configuration management systems first came with template engines and now require a separate tool to render the configuration. Nobody would develop anything like that if it was not needed.
- Fischgericht 3y ago
  Oh yes, people DO develop stuff that is not needed. Back in the 90ies pretty much every nerd sooner or later had to write his own programming language (myself included). The difference between then and today: We did throw it away afterwards. These days every week someone spews out a new "programming language", claiming that the re-invented wheel is so much more round than the others. If fully agree that you might need to automate editing and deploying config files. But you don't need a new programming language for that. Just use one of the thousands of existing languages and tools. You can for example use sed. A standard since 1973. Available everywhere. 76KB in size. Extremely fast. Or use AWK. Exists since 1977. Or you can use Perl. Natively able to read/write ini files, and in general very good at string processing. 6MB in size (or 250KB for embedded versions). Or use Javascript, PHP, shell scripting, whatever. But no, there is absolutely no need to invent a new programming language for a task where there are very established tools for.
  - __MatrixMan__ 3y ago
    I stopped using sed because it behaved differently on my coworker's machine than it did on mine.
    - hot_gril 3y ago
      Same, actually a lot of the listed things are too old-school for me.
  - 3y ago
mbesto 3y ago
25 years ago, you didn't have thousands of websites and applications supporting billions of users and millions of TPS. In hindsight, the innovation around DevOps is nothing short of a marvel IMO. 87 MB in the context of a $100 16GB stick of RAM is basically cheap in relative terms.
jayd16 3y ago
> manually crate a ... config file. Wouldn't you want to self host the config?
__MatrixMan__ 3y ago
25 years ago, the only way to get two pieces of software to talk to each other was to get their authors to talk to each other. I'm quite happy that remix culture has finally made it to software tooling. The extra layer of abstraction is a small price to pay for the power it brings. (I don't know Pkl, but it seems like it scratches part of the same itch that you might use nix for).
Bost 3y ago
> So what we are missing now is a 500GB framework that can write the config file for the programming language that is writing a config file for the actual program I wish to use. That exists since 1960. It's called LISP. The e.g. https://guix.gnu.org/ https://guix.gnu.org/ uses with great success, the Guile Scheme dialect of LISP, to be precise. And FYI the "framework" is: $ ls --human-readable --size $(readlink $(which guile)) 16K /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9/bin/guile Yes, only sixteen kilos, not gigas.
- iso8859-1 3y ago
  Guix/Nix can use dynamic linking without risk since they know the exact dependency closure. It's not fair to compare a statically linked executable to a dynamic one.
  - panzi 3y ago
    Right, so its still just about 9 MB: guile=$(readlink -f $(which guile)) sizes=$({ echo $guile; ldd $guile|grep /|sed 's+^[^/]*$/[^ ]*$.*+\1+'; }|xargs -n 1 readlink -f|xargs du -ab|cut -f 1) sumsize=0 for size in $sizes; do sumsize=$((sumsize+size)); done echo $sumsize Gives 9041632 here.
    - Bost 3y ago
      Thanks for the snippet. Now I have a recipe how to calculate the size of a binary file, plus the shared objects, i.e. the so-file(s), it requires directly. Now I just need to extend your snippet so that it works recursively. A shared object can require other shared objects.
pradn 3y ago
The general shift to infrastructure-as-code is tied to a number of new trends and requirements: 1) Code review (config code can be reviewed by humans) 2) Automated pre-submit checks (config code can passed through automated pre-submit checks - such as preventing huge changes, or giving you a nice diff to look at 3) Auditability / history-tracking (you can look at the history of a config file to see who, when, why changes were made - this may even be necessary for compliance reasons) 4) De-duplication (you can extract common components into templates/functions - this supports variation across envs/regions/customers and repetition across tasks/machines/DBs) All of these features help build large-scale systems in modern corporate environments.
koromak 3y ago
40 years ago I wrote Assembly that ran directly on the CPU. You could modify the registers directly. Then these crazy people came along and made a compiled language? And it outputs... Assembly? I'm sorry, but a huge chunk of todays "developers" really are in the business of creating problems.
- bsdpufferfish 3y ago
  except when you moved to C there was no corresponding increase in fixed time which you must spend on tool setup just to program
  - jhardy54 3y ago
    Yeah, it’s really great that compiling C is a straightforward endeavor that doesn’t require any tools, and definitely doesn’t depend on executables that generate or parse configuration files. I’m confident that no C developers have ever spent time on tool setup just to program.
    - bsdpufferfish 3y ago
      gcc main.c Of course tinkerers made some tools you can tinker with as time went on, but you don’t have to let those interfere with velocity, just like I will not be using configuration languages.
      - jhardy54 3y ago
        Do you mind linking me to some large C projects that don’t use make/autotools/etc?
        bsdpufferfish 3y ago
        stb libraries
        3y ago
chadcmulligan 3y ago
I'm convinced some developers are copying the lawyers old scam of charging by the word why else would we have this nonsense
HacklesRaised 3y ago
I think there are plenty of people who have the same uncomfortable feeling. I used to see this sort of thing a lot at Apple and I used to classify the people concerned as those that work AT Apple rather than people that work FOR Apple.

afavour 3y ago

That strikes me as a very uncurious perspective. There’s absolutely nothing that could be improved about configuration files? An 87MB binary feels like a very arbitrary measure of worthiness.

Aeolun 3y ago
I mean, there is something to be said against using the equivalent of 87 novels worth of text to produce a note’s worth of configuration.
Fischgericht 3y ago
ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS. And again: If your config files are so complex, how about just creating a TUI/GUI so the user can configure your program in an accessible fashion? Anyway, yes, there is something that can be improved: Create a standard instead of adding another layer of complexity for something that should be very simple in the first place. Yes, binary size may feel arbitrary, but it often gives a hint about the hammer's size.
- ivlad 3y ago
  > TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS. INI is hard to parse because without quotes the parser would not know whether it’s a “True” as a string or True as Boolean value. Formal parser that can be included into a program as a library and would reliably generate internal config representation (e.g., read config file into an object in application memory that will be used to modify the behaviour) is a good thing and TOML helps with that while INI does not.
  - mixmastamyk 3y ago
    Schemas are often better than syntax typing. In other words the program decides what the type is, not the file.
    - Silphendio 3y ago
      If the schema allows union types, I don't want to deal with unquoted strings.
      - mixmastamyk 3y ago
        You don’t deal with syntax period. Union types are not desirable with configuration with the exception of |null perhaps, which should receive a default.
  - Fischgericht 3y ago
    Yes, agreed. On the other hand, there are quite a few people using Javascript, a language where this distinction also isn't really done in a clean way. If you would de-serialize an ini-file into Objects in memory you would typically have meta-data about your object (RTTI/Reflection for compiled languages, given for scripting languages). But yes, INI isn't without flaws. Parsers typically will need to accept everything from "true", "True", True, true, 1, "1" for boolean fields.
- 3y ago

n42 3y ago

Yes, the windows registry, the peak of our craft. No need to innovate, this one’s solved, wrap it up and move on Try taking more time to consider the problems you don’t have that others do, instead of writing anything off that doesn’t make sense to you (and simultaneously gatekeeping an entire industry)

sigzero 3y ago
I am taking your comment as a joke because the Windows Registry is a joke.
- fallensatan 3y ago
  I think they are being sarcastic about windows registry.
Fischgericht 3y ago
Creating complex layers upon layers just to "solve" a very simple problem is not innovation. It's shittification.
- cqqxo4zV46cp 3y ago
  Misappropriating a trendy word to use as a descriptor for anything you don’t like. This is how someone speaks immediately before taking a look in the mirror and realising that they sound like their parents. You are not the be-all end-all and your drive-by analysis of a technology is going to be biased by its suitability for what you do day-to-day. No amount of experience justifies your attitude.
  - Fischgericht 3y ago
    I am sorry if the wording of my opinion has offended you. My parents most likely would have complained that they'd need 58 floppy disks to run this programming language. :)
    - 3y ago

ivlad 3y ago

25 years ago admin would be responsible for one server, that they would setup and then never touch until (and sometimes after) someone hacked it. Now people are responsible for thousands of containers, and GUI simply does not scale. And the configuration of those containers is domain-specific and/or varies enough so that you cannot write a single config file and copy it over. This is why configuration management systems first came with template engines and now require a separate tool to render the configuration. Nobody would develop anything like that if it was not needed.

Fischgericht 3y ago
Oh yes, people DO develop stuff that is not needed. Back in the 90ies pretty much every nerd sooner or later had to write his own programming language (myself included). The difference between then and today: We did throw it away afterwards. These days every week someone spews out a new "programming language", claiming that the re-invented wheel is so much more round than the others. If fully agree that you might need to automate editing and deploying config files. But you don't need a new programming language for that. Just use one of the thousands of existing languages and tools. You can for example use sed. A standard since 1973. Available everywhere. 76KB in size. Extremely fast. Or use AWK. Exists since 1977. Or you can use Perl. Natively able to read/write ini files, and in general very good at string processing. 6MB in size (or 250KB for embedded versions). Or use Javascript, PHP, shell scripting, whatever. But no, there is absolutely no need to invent a new programming language for a task where there are very established tools for.
- __MatrixMan__ 3y ago
  I stopped using sed because it behaved differently on my coworker's machine than it did on mine.
  - hot_gril 3y ago
    Same, actually a lot of the listed things are too old-school for me.
- 3y ago

mbesto 3y ago

25 years ago, you didn't have thousands of websites and applications supporting billions of users and millions of TPS. In hindsight, the innovation around DevOps is nothing short of a marvel IMO. 87 MB in the context of a $100 16GB stick of RAM is basically cheap in relative terms.

jayd16 3y ago

> manually crate a ... config file. Wouldn't you want to self host the config?

__MatrixMan__ 3y ago

25 years ago, the only way to get two pieces of software to talk to each other was to get their authors to talk to each other. I'm quite happy that remix culture has finally made it to software tooling. The extra layer of abstraction is a small price to pay for the power it brings. (I don't know Pkl, but it seems like it scratches part of the same itch that you might use nix for).

Bost 3y ago

> So what we are missing now is a 500GB framework that can write the config file for the programming language that is writing a config file for the actual program I wish to use. That exists since 1960. It's called LISP. The e.g. https://guix.gnu.org/ https://guix.gnu.org/ uses with great success, the Guile Scheme dialect of LISP, to be precise. And FYI the "framework" is: $ ls --human-readable --size $(readlink $(which guile)) 16K /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9/bin/guile Yes, only sixteen kilos, not gigas.

iso8859-1 3y ago
Guix/Nix can use dynamic linking without risk since they know the exact dependency closure. It's not fair to compare a statically linked executable to a dynamic one.
- panzi 3y ago
  Right, so its still just about 9 MB: guile=$(readlink -f $(which guile)) sizes=$({ echo $guile; ldd $guile|grep /|sed 's+^[^/]*$/[^ ]*$.*+\1+'; }|xargs -n 1 readlink -f|xargs du -ab|cut -f 1) sumsize=0 for size in $sizes; do sumsize=$((sumsize+size)); done echo $sumsize Gives 9041632 here.
  - Bost 3y ago
    Thanks for the snippet. Now I have a recipe how to calculate the size of a binary file, plus the shared objects, i.e. the so-file(s), it requires directly. Now I just need to extend your snippet so that it works recursively. A shared object can require other shared objects.

pradn 3y ago

The general shift to infrastructure-as-code is tied to a number of new trends and requirements: 1) Code review (config code can be reviewed by humans) 2) Automated pre-submit checks (config code can passed through automated pre-submit checks - such as preventing huge changes, or giving you a nice diff to look at 3) Auditability / history-tracking (you can look at the history of a config file to see who, when, why changes were made - this may even be necessary for compliance reasons) 4) De-duplication (you can extract common components into templates/functions - this supports variation across envs/regions/customers and repetition across tasks/machines/DBs) All of these features help build large-scale systems in modern corporate environments.

koromak 3y ago

40 years ago I wrote Assembly that ran directly on the CPU. You could modify the registers directly. Then these crazy people came along and made a compiled language? And it outputs... Assembly? I'm sorry, but a huge chunk of todays "developers" really are in the business of creating problems.

bsdpufferfish 3y ago
except when you moved to C there was no corresponding increase in fixed time which you must spend on tool setup just to program
- jhardy54 3y ago
  Yeah, it’s really great that compiling C is a straightforward endeavor that doesn’t require any tools, and definitely doesn’t depend on executables that generate or parse configuration files. I’m confident that no C developers have ever spent time on tool setup just to program.
  - bsdpufferfish 3y ago
    gcc main.c Of course tinkerers made some tools you can tinker with as time went on, but you don’t have to let those interfere with velocity, just like I will not be using configuration languages.
    - jhardy54 3y ago
      Do you mind linking me to some large C projects that don’t use make/autotools/etc?
      - bsdpufferfish 3y ago
        stb libraries
        3y ago

chadcmulligan 3y ago

I'm convinced some developers are copying the lawyers old scam of charging by the word why else would we have this nonsense

HacklesRaised 3y ago

I think there are plenty of people who have the same uncomfortable feeling. I used to see this sort of thing a lot at Apple and I used to classify the people concerned as those that work AT Apple rather than people that work FOR Apple.