7 ms·

Sounds like another short sighted decision. Why don't they support an intermediatory representation that many languages can support. Even yaml would be fine if

Sounds like another short sighted decision. Why don't they support an intermediatory representation that many languages can support. Even yaml would be fine if other languages can generate it. If they had to absolutely use something why not something more main stream and popular like Python. Helm asks too much for the functionality it provides.

silon42 7y ago
-1 for Turing complete config languages.
- vardump 7y ago
  Any reason why you think they're bad? Sounds enticing to me to be able to have a bit of logic in configuration file.
  - bmn__ 7y ago
    https://news.ycombinator.com/item?id=17186338 https://news.ycombinator.com/item?id=17186338
  - duncanawoods 7y ago
    Programming language design and implementation is a huge and hard problem. What you get is an incomplete frustrating language full of semantic oddities and confusions without any serious support tooling to help you out. If you use it in anger, you quickly need all language features e.g. importing libraries, namespaces, functions, data-structures, rich string manipulation etc. But you rarely get these. At run-time, you don’t have a debugger or anything leading to a maddening bug fix experience because config cycle times are really high. Because it’s a niche language, only one poor soul in a team ends up the expert of all the plentiful traps. Eventually... you give up and end up generating the config in a proper language and it feels like a breath of fresh air.
    - DonHopkins 7y ago
      One of the most ridiculous examples of this was the Smarty templating language for PHP. Somebody got the silly idea in their head of implementing a templating language in PHP, even though PHP is ALREADY a templating language. So they took out all the useful features of PHP, then stuck a few of them back in with even goofier inconsistent hard-to-learn syntax, in a way that required a code generation step, and made templates absolutely impossible to debug. So in the end your template programmers need to know something just as difficult as PHP itself, yet even more esoteric and less well documented, and it doesn't even end up saving PHP programmers any time, either. https://web.archive.org/web/20100226023855/http://lutt.se/blog/2006/08/13/why-template-engines-like-smarty-sucks-in-php.html https://web.archive.org/web/20100226023855/http://lutt.se/bl... >Bad things you accomplish when using Smarty: >Adding a second language to program in, and increasing the complexity. And the language is not well spread at all, allthough it is’nt hard to learn. >Not really making the code more readable for the designer. >You include a lot of code which, in my eyes, is just overkill (more code to parse means slower sites). https://web.archive.org/web/20090227001433/http://www.ranting-wolf.info/2008/03/21/php-truth-about-short-open-tags-and-smarty/ https://web.archive.org/web/20090227001433/http://www.rantin... >Most people would argue, that Smarty is a good solution for templating. I really can’t see any valid reasons, that that is so. Specially since “Templating” and “Language” should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is “better for designers, since they don’t need to learn PHP!”. Wait. What? You’re not learning one programming language, but you’re learning some other? What’s the point in that, anyway? Do us all a favour, and just think the next time you issue that statement, okay? http://www.ianbicking.org/php-ghetto.html http://www.ianbicking.org/php-ghetto.html >I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.
- DonHopkins 7y ago
  +1 for Turing complete programming languages instead of half-assed config languages.
  - deleted 7y ago
    [deleted]
  - SomeOldThrow 7y ago
    Why are you putting logic in the config in the first place? Just let it be data.
    - DonHopkins 7y ago
      That's like saying that God existed before creating the universe. Then you have to ask who created God? And if God was created only from data and not any logic, then the config file must have been really huge and unmaintainable.
      - SomeOldThrow 7y ago
        Do you have an example of when logic would help a configuration file? Their value and use are entirely dependent on the context. Also I can't make a head or tail of your statement, no offense intended—I can make out parts, but the whole just has no meaning to me.
        DonHopkins 7y ago
        Given any non-trivial data-only config file, it will always grow to the point that you'll end up needing to generate it automatically with logic. And that goes double for God's config file.
        SomeOldThrow 7y ago
        Do you have an example? I don't think I've ever needed to generate a config automatically (except in niche cases like generating configs for services in chef), and if I'm understanding correctly, nothing proposed in this thread would help with that scenario. I suspect you're front-loading a lot of logic from the app bootup into the config file, and I'm not sure what you stand to gain conflating those two things. Like—what's the execution order of a config file? Can you refer to a value later in the file? If so, how does it determine which value is executed before the next? If not, how do you setup circular dependencies—can you redefine config values halfway through a file? If not, you're gonna have to fall back on at-boot pre-processing anyway with sufficient complexity, so just treat a config like dumb data to begin with and do all your logic in the bootup and put all the values/whatever in the config file. And god knows, I would be strongly tempted to murder an engineer that introduced a config file capable of rewriting itself—that engineer has clearly never needed to debug another person's shitty code before.
- yellowapple 7y ago
  How about normally-Turing-complete languages that can be stripped down to non-Turing-completeness to make a configuration DSL? This is exactly what Tcl supports / was designed to do (and in turn is one of my motivations for developing OTPCL). This is also exactly what your average Lisp or Scheme supports.

silon42 7y ago

-1 for Turing complete config languages.

vardump 7y ago
Any reason why you think they're bad? Sounds enticing to me to be able to have a bit of logic in configuration file.
- bmn__ 7y ago
  https://news.ycombinator.com/item?id=17186338 https://news.ycombinator.com/item?id=17186338
- duncanawoods 7y ago
  Programming language design and implementation is a huge and hard problem. What you get is an incomplete frustrating language full of semantic oddities and confusions without any serious support tooling to help you out. If you use it in anger, you quickly need all language features e.g. importing libraries, namespaces, functions, data-structures, rich string manipulation etc. But you rarely get these. At run-time, you don’t have a debugger or anything leading to a maddening bug fix experience because config cycle times are really high. Because it’s a niche language, only one poor soul in a team ends up the expert of all the plentiful traps. Eventually... you give up and end up generating the config in a proper language and it feels like a breath of fresh air.
  - DonHopkins 7y ago
    One of the most ridiculous examples of this was the Smarty templating language for PHP. Somebody got the silly idea in their head of implementing a templating language in PHP, even though PHP is ALREADY a templating language. So they took out all the useful features of PHP, then stuck a few of them back in with even goofier inconsistent hard-to-learn syntax, in a way that required a code generation step, and made templates absolutely impossible to debug. So in the end your template programmers need to know something just as difficult as PHP itself, yet even more esoteric and less well documented, and it doesn't even end up saving PHP programmers any time, either. https://web.archive.org/web/20100226023855/http://lutt.se/blog/2006/08/13/why-template-engines-like-smarty-sucks-in-php.html https://web.archive.org/web/20100226023855/http://lutt.se/bl... >Bad things you accomplish when using Smarty: >Adding a second language to program in, and increasing the complexity. And the language is not well spread at all, allthough it is’nt hard to learn. >Not really making the code more readable for the designer. >You include a lot of code which, in my eyes, is just overkill (more code to parse means slower sites). https://web.archive.org/web/20090227001433/http://www.ranting-wolf.info/2008/03/21/php-truth-about-short-open-tags-and-smarty/ https://web.archive.org/web/20090227001433/http://www.rantin... >Most people would argue, that Smarty is a good solution for templating. I really can’t see any valid reasons, that that is so. Specially since “Templating” and “Language” should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is “better for designers, since they don’t need to learn PHP!”. Wait. What? You’re not learning one programming language, but you’re learning some other? What’s the point in that, anyway? Do us all a favour, and just think the next time you issue that statement, okay? http://www.ianbicking.org/php-ghetto.html http://www.ianbicking.org/php-ghetto.html >I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.
DonHopkins 7y ago
+1 for Turing complete programming languages instead of half-assed config languages.
- deleted 7y ago
  [deleted]
- SomeOldThrow 7y ago
  Why are you putting logic in the config in the first place? Just let it be data.
  - DonHopkins 7y ago
    That's like saying that God existed before creating the universe. Then you have to ask who created God? And if God was created only from data and not any logic, then the config file must have been really huge and unmaintainable.
    - SomeOldThrow 7y ago
      Do you have an example of when logic would help a configuration file? Their value and use are entirely dependent on the context. Also I can't make a head or tail of your statement, no offense intended—I can make out parts, but the whole just has no meaning to me.
      - DonHopkins 7y ago
        Given any non-trivial data-only config file, it will always grow to the point that you'll end up needing to generate it automatically with logic. And that goes double for God's config file.
        SomeOldThrow 7y ago
        Do you have an example? I don't think I've ever needed to generate a config automatically (except in niche cases like generating configs for services in chef), and if I'm understanding correctly, nothing proposed in this thread would help with that scenario. I suspect you're front-loading a lot of logic from the app bootup into the config file, and I'm not sure what you stand to gain conflating those two things. Like—what's the execution order of a config file? Can you refer to a value later in the file? If so, how does it determine which value is executed before the next? If not, how do you setup circular dependencies—can you redefine config values halfway through a file? If not, you're gonna have to fall back on at-boot pre-processing anyway with sufficient complexity, so just treat a config like dumb data to begin with and do all your logic in the bootup and put all the values/whatever in the config file. And god knows, I would be strongly tempted to murder an engineer that introduced a config file capable of rewriting itself—that engineer has clearly never needed to debug another person's shitty code before.
yellowapple 7y ago
How about normally-Turing-complete languages that can be stripped down to non-Turing-completeness to make a configuration DSL? This is exactly what Tcl supports / was designed to do (and in turn is one of my motivations for developing OTPCL). This is also exactly what your average Lisp or Scheme supports.