Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are we templating YAML?

leebriggs.co.uk

Post reply on HN
Print view View original

281–290 of 351 posts

Re: Why are we templating YAML?

#281

Post by marcosdumay »

kakarot wrote: post #244
fulafel wrote: post #202

Earlier quoted context omitted.

In the YAML case: It's hard if you don't have editor support and good diagnostics. Not because you're unusually sloppy, but because you make human mistakes and because you don't know the syntax. (YAML syntax is surprisingly complex and poorly documented in the pedagogic sense). Also, the edit-debug cycle is slow with Ansible or YAML-using CI systems, so this is doubly painful. In the Python case it's much better, bec…

Everything is hard when you don't have editor support and good diagnostics. Don't blame YAML because you prefer to use Notepad.exe However, missing/extra whitespace is not "hard". You would be docked points in an English paper and you should be docked points as a programmer. So, whitespace aside... Tell me what is easier to edit without built-in syntax support: JSON, or YAML? If we define "easy" as "how long it takes…

Editing JSON is ok without specific format support, it just looks like any other C-like language. Editing YAML is basically impossible without specific support, your editor will almost certainly break any file you open and destroy relevant information on the process.

Re: Why are we templating YAML?

#282

Post by kakarot »

ex3ndr wrote: post #279
kakarot wrote: post #242

Earlier quoted context omitted.

What's magic about webpack? The online documentation provides quite a lot of insight into how it all fits together. It probably only seems like magic because you didn't build a fundamental understanding of how it works before using it. I use some massive webpack configurations and I understand them all quite thoroughly thanks to well-written, modularized configuration files.

For 10 years of Java/Android/Scala coding there was no need to understand how compilers combine everything into one JAR.

Javascript is a scripting language without native module support. That isn't Webpack's fault.

Webpack also handles much, much more than just Javascript. It handles CSS, HTML, images, files, pretty much any kind of asset. Java/Scala doesn't have anything like that. Asset management is completely different due to the nature of how assets are transferred to the client.

And Android? Give me a break. The moment you stray from the strict layout of an Android app you run into a wall and have to learn how Gradle operates. This strict layout is good for some but others hate when an environment forces particular constraints upon them.

Webpack is completely configurable at every stage, works with plugins (which compilers don't do) and again, isn't magic. Not knowing how something works doesn't make it magic. That's not what magic means with respect to code.

Besides... Maybe if you just like getting by, you can program in C/Java/etc without learning about compilers. Web dev is fucked and transpiler knowledge is basically required, but sure you can get by in other domains without it. But if you want to be a good programmer, an expert at what you do, someone who lives and breathes and understands computer science, someone who will excel in his career and not remain a code monkey forever... You have to learn about how your compilers work just like you should know how the silicon in your computer is doing its own "magic".

Re: Why are we templating YAML?

#283

Post by fulafel »

kakarot wrote: post #244
fulafel wrote: post #202

Earlier quoted context omitted.

In the YAML case: It's hard if you don't have editor support and good diagnostics. Not because you're unusually sloppy, but because you make human mistakes and because you don't know the syntax. (YAML syntax is surprisingly complex and poorly documented in the pedagogic sense). Also, the edit-debug cycle is slow with Ansible or YAML-using CI systems, so this is doubly painful. In the Python case it's much better, bec…

Everything is hard when you don't have editor support and good diagnostics. Don't blame YAML because you prefer to use Notepad.exe However, missing/extra whitespace is not "hard". You would be docked points in an English paper and you should be docked points as a programmer. So, whitespace aside... Tell me what is easier to edit without built-in syntax support: JSON, or YAML? If we define "easy" as "how long it takes…

I see you restate your argument for clarity, let me try the same :)

1) YAML is a configuration file format, and it's targeting user groups and environments where people use ad hoc terminal based or os-bundled editors, such tools being nano or Notepad, and such users being sysadmins for example. 2) YAML implementations (=parsers) have poor diagnostics compared to Python, separate from the editor issue, and 3) YAML syntax is more prone than Python to parsing correctly but producing unwanted semantics when you make a mistake.

I think there is value in your English paper analogy: many/most people editing YAML files don't know YAML syntax very well compared to this scenario. If their knowledge of English was at the same level, misplaced whitespace would not be chief of their problems in a graded English paper.

It is of course a structurally valid (philosophically consistent) argument that people should not make mistakes and they should suffer when they do, but this goes generally against the consensus of configuration language usability thinking.

Re: Why are we templating YAML?

#284

Post by svsucculents »

sametmax wrote: post #220
joeduffy wrote: post #57

My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren't sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) p…

There are several possible situations: - the django like situation: the configuration is pure code, and it's a mistake. It was not necessary, it brought plenty of problems. I wish they went with a templated toml file. - the ansible like situation: the configuration is templated static text. But with something as complex as deployment, they ended up adding more and more constructs, until they created a monstrous DSL o…

After years of working with cfengine then ansible I finally went to a bespoke BSD ports work alike with optional client/server and json configuration components. Never looked back.

Re: Why are we templating YAML?

#285

Post by eadmund »

macspoofing wrote: post #62
SamWhited wrote: post #32

As others in this thread have said: I ask this question all the time, except s/templating/using/. YAML is insanely over complicated; it's as bad or worse than XML for config files, and it doesn't even have the nice streaming mode. Not to mention that it's a bit of a security nightmare (seriously, who put pointers into the YAML spec?). And, on a more subjective note, YAML is just confusing: between all the significant…

>it's as bad or worse than XML for config files XML works very well for config files. It's schema-optional (but is there), well-specified, human-readable, has plethora of supporting technologies (making things like templating easy), and is well supported by every language. At the very least it is way better than JSON.

There's absolutely no way that this (copied from https://github.com/akeeba/fof/wiki/The-XML-configuration-fil...):

    
    
        
        
            
            
                
            
    
            
            
                items
            
            
            
            
                ABCD123456
                HTTPBasicAuth_TOTP,QueryString_TOTP
            
    
            
            
                
                
                    
                
            
                
                published
    
                
                
                
                
    
                
                foo,bar,baz
            
    
            
            
                
                
                    browse
                
                
                
                
                    
                    core.manage
                
                
                
                
                    3
is at all preferable to this:

    (fof
     (common
      (container (component-namespace "MyCompany\\MyApplication"))
    
      (dispatcher (default-view items))
    
      (authentication
       (totp-key ABCD123456)
       (authentication-methods (http-basic-auth-totp query-string-totp)))
    
      (model orders
             (config (tbl "#__fakeapp_orders"))
             ;; Field aliasing. One tag per aliased field
             (field enabled published)
    
             ;; Relation setup. One tag per relation
             (relation items (type has-many))
             (relation transaction (type belongs-to-many)
                       (local-key "foobar_order_id")
                       (foreign-key "foobar_transaction_id")
                       (pivot-local-key "foobar_order_id")
                       (pivot-foreign-key "foobar_transaction_id")
                       pivot-table "#__foobar_orders_transactions")
             (relation client (type belongs-to)
                       (foreign-model-class "Users@com_fakeapp"))
    
             ;; Behaviour setup. Use merge="1" to merge with already defined behaviours.
             (behaviors (merge 1) (foo bar baz)))
    
      ;; Controller, View and Toolbar setup. One tag per view.
      (view item
            (taskmap (list browse))
    
            ;;  Controller ACL mapping
            (acl
             (task dosomething)
             (task somethingelse core.manage))
    
            ;; Controller and View options
            (config (auto-routing 3))
    
            ;; Toolbar configuration
            (toolbar "COM_FOOBAR_TOOLBAR_ITEM"
                     (task edit)
                     (button save)
                     (button saveclose)
                     (button savenew)
                     (button cancel))))
    
     (backend)
     (frontend))
There's just no way.

Re: Why are we templating YAML?

#286

Post by jaxxstorm »

joeduffy wrote: post #197
jaxxstorm wrote: post #173

Earlier quoted context omitted.

OP here. I actually wrote a post about Pulumi in this very space a while back https://leebriggs.co.uk/blog/2018/09/20/using-pulumi-for-k8s... I do think this is more like what we should be doing, but as dismayed to see Pulumi’s free tier get sunsetted

Our free tier is still there and here to stay. What did we do to make you think it's been sunsetted? :-(

Oh! I don’t know where I got that impression from then! perhaps I just thought that we couldn’t use the free tier because of the number of licenses we’d need, but you’re right, it’s still there!

Re: Why are we templating YAML?

#287

Post by epage »

wryun wrote: post #89
epage wrote: post #65

There have been times I've wanted to templatize my configuration but I don't want to do it with text-based templates but templates within the configuration files syntax (be it yaml, toml, or something else). Not sure what this is called, I've been calling it "structural templating". So far the only things close to this are - Azure pipeline's syntax: https://docs.microsoft.com/en-us/azure/devops/pipelines/proc... - So…

I prefer https://github.com/taskcluster/json-e Has the advantage/disadvantage that it's still valid json/yaml I wrote a scary command line wrapper for it: https://wryun.github.io/rjsone/ Has libs for Python, Go, and JS, and there's a bazel interface.

This looks really nice. I'll have to give this a try at some point to see how I feel about it vs Azure Pipelines. From my quick look, this looks more general purpose at the cost of more verbosity.

Re: Why are we templating YAML?

#288

Post by mschaef »

pjc50 wrote: post #251
rauhl wrote: post #97

Earlier quoted context omitted.

> My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. I think that you’re right, and I think it’s great, because we have a programming model in which code is data and data is code: Lisp & S-expressions. It’d be downright awesome to have a Lisp-based system which used dynamic sc…

As the kids say: stop trying to make Lisp happen, it's not going to happen. It has become yet another community that's fighting a struggle that everyone else ended years ago, like the few Japanese in jungles who refused to surrender. I'm not entirely sure why it's not been adopted, but I suspect it's because most people strongly prefer (a) visually semantically different scope delimiters and (b) function-outside-brac…

> It has become yet another community that's fighting a struggle that everyone else ended years ago, ... like the few Japanese in jungles who refused to surrender.

Nice imagery, but the wrong point.

Except for the syntax, everybody else joined Lisp.

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." --Guy Steele

Flash back to the mid-1980's (when the mainstream was C, Pascal, BASIC, FORTRAN, COBOL, etc.) and it's Lisp/Scheme (and Smalltalk) that have features like Garbage Collection, interactive development, lexical closures, decent built-in data structures, dynamic typing.

The fact that all of this is commonplace today, both justifies a lot what Lisp did in the first half of its existence and undermines its (technical) competitive advantages now.

> but I suspect it's because most people strongly prefer (a) visually semantically different scope delimiters and (b) function-outside-brackets syntax ie f(a, b) rather than (f a b).

It's not technical. I don't think it ever was. So much of it is around social concerns: a performance stigma dating back to the 1970's, fear of being able to hire people to do the work, fear of what VC's will think, worries that the language will still be available... And then at the end of the day, the problems whatever language will solve are a tiny fraction of the overall problem of doing something relevant and lasting and useful to others.

> As the kids say: stop trying to make Lisp happen, it's not going to happen.

Life is too short and the world is too big to try to confine other people's ideas of how they should think or work.

The point of the market economy and of the scientific process is that people get to try what they think is going to be useful and then let the world decide. The fact that Lisp is still in the conversation at all, when its contemporaries (Autocoder, Fortran) either aren't or are highly specialized, says a lot that we can learn from.

Re: Why are we templating YAML?

#289

Post by mschaef »

marcosdumay wrote: post #270
ajross wrote: post #154

Earlier quoted context omitted.

> I think that you’re right, and I think it’s great, because we have a programming model in which code is data and data is code: Lisp & S-expressions. " Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp. " http://wiki.c2.com/?GreenspunsTenthRuleOfProgramming Seriously, this has happened again and again and again. You have…

That saying was very true of Fortran, reasonably true of C, and mostly don't happen on newer languages.

I think the parts of Lisp that tended to be rebuilt have mostly been incorporated into the newer languages. (At least, it's been a very long time since I've had to rewrite a fundamental data structure, etc.)

Re: Why are we templating YAML?

#290

Post by fasteo »

Off-topic: The whole discussion is about deploy-time configuration management, but our problem is more about run-time configuration management.

We have done the classical memcached+database custom solution, but I was wondering if there is any accepted library/tool to change application run-time behavior. We have tried consul KV store [1], but does not quite fit in our environment.

My ideal solution would be a webapp with some text editor (think codemirror). Changes in this text file would push the configuration data to a running application.

[1] https://learn.hashicorp.com/consul/getting-started/kv

Post reply on HN