[chef-dev] Re: Re: Re: Dialect support and loading enhancements

[Noah Kantrowitz < >]

On Sep 20, 2013, at 3:58 PM, Lamont Granquist 
<
 >
 wrote:

> On 9/20/13 12:17 PM, Brad Knowles wrote:
>> On Sep 19, 2013, at 9:39 PM, Adam Jacob 
>> <
 >
>>  wrote:
>> 
>>> It's interesting to hear you say you feel like you don't know how to 
>>> program, when i've seen you be an effective member of our community for a 
>>> long time now. Is it completely out of school to say that perhaps you're 
>>> arguing for your limitations? You might not be a CS major - lord knows, 
>>> I'm not. But you do know how to program, and you're doing it in ruby. :) 
>>> The closest you've come to a real programming language is Ruby: you're 
>>> programming in it, and have been the entire time you've rocked the Chef, 
>>> an you've done so successfully.
>> I have a BSCS from the College of Engineering at the University of 
>> Oklahoma, technically dated 1990 although I completed my last bit of work 
>> in 1989.  While at University, in terms of formal programming languages I 
>> learned COBOL, FORTRAN, IBM System 360 Assembly, Prolog, and others.  I'm 
>> old enough that I actually pre-date ANSI-C, and I have both 1st and 2nd 
>> editions of K&R.  The first program I ever wrote was an implementation of 
>> a complete "choose your own adventure" book in Basic, on a Commodore 
>> Vic-20, when I was 14 -- it was kinda-semi-sorta Zork-like, although I 
>> didn't learn about Zork until many years later.
> Okay, you totally opened the door there to me one-upping your 
> grumpy-old-man all over this thread...
> 
> I learned 6502 assembly language in Junior High school and learned K&R C on 
> a Tandy 6000 running Xenix.  I got my first Junior SA job in college 
> managing a heterogenous mess of Digital Unix, Solaris, SunOS 4.1.x, NetBSD, 
> Irix, Mac and NT.  I've always been a programmer (writing scripts to make 
> the machine do a thing) rather than a software developer (designing objects 
> and abstractions to make an extendable platform).  I wrote thousands of 
> lines of (retrospectively) awful perl and cfengine scripts to keep Amazon 
> and Real Networks running, but nothing that would be considered "software". 
>  At the tender age of 39 I got sick of operations, and couldn't see myself 
> landing another job in ops, and I was impatient with the devops revolution 
> and so I switched to being a full time SDE and learning ruby and new rules 
> like "use composition instead of inheritance" and started noodling on rails 
> and angular websites in my spare time.  The shift was midly terrifying at 
> times, but not as radical as I expected.   I think most of the barrier 
> between programmer and software dev is mostly in learning a different 
> *human* language, and it takes immersion in the culture to do it. For me, I 
> don't learn well through theory and reading dissertations on a subject but 
> more from rolling up my sleeves and trying it until it breaks, which is why 
> I had a really hard time becoming a software dev without actually being a 
> software dev.  I have to sit down and struggle with writing 1,000s of lines 
> of ugly rspec code before I understand why too much collaboration in an 
> object model is bad -- its because you wind up with the unit tests for the 
> file provider. A lot of software development isn't very creative at all, 
> its just having experience, so that you can see that a bit of code is bad 
> because its bad the way that other pieces of code were bad before it.  And 
> learning from more senior devs who have already written all the bad code 
> and learned to write better code and then just applying those patterns to 
> the code you write in the future, and a lot of incremental improvement 
> rather than any kind of insightful genius. A year or two later you just 
> notice that you can sit down at a computer and the code that you type up is 
> naturally become much better.
> 
> Anyway...
> 
> Compare these two examples:
> 
> SALT:
> 
> {% if grains['os'] != 'FreeBSD' %}
> tcsh:
>    pkg:
>        - installed
> {% endif %}
> 
> motd:
>  file.managed:
>    {% if grains['os'] == 'FreeBSD' %}
>    - name: /etc/motd
>    {% elif grains['os'] == 'Debian' %}
>    - name: /etc/motd.tail
>    {% endif %}
>    - source: salt://motd
> 
> 
> CHEF:
> 
> if node['platform'] != "FreeBSD"
>  package "tcsh"
> end
> 
> motd_path = case node['platform']
>  when "FreeBSD"
>    "/etc/motd"
>  when "Debian"
>    "/etc/motd.tail"
>  end
> 
> cookbook_file motd_path do
>  source "motd"
> end
> 

Again, I want to reiterate that no part of this proposal involves adding 
jinja+yaml or erb+yaml to Chef. It does mean the hooks will be in place such 
that someone could write that externally, and if for some reason it catches 
on and becomes popular then I will eat my words and move on, but my vote is 
most definitely for leaving it out until that point. The places Yaml would be 
added are either things that are already fully static/declarative (roles, 
data bags, maybe metadata.yml for cookbooks but I'm kind of meh on that) and 
attribute files as a special case where the vast majority of the time they 
are fully declarative and static. If you objection is that it should 100% 
impossible to create a jinja+yaml plugin for Chef, I think the existence of 
chef-funnel definitely shows it is possible already, so the only thing 
stopping people is just that I'm the only one crazy enough to try such things 
so far. I will definitely do my best to make sure any dialects I write or am 
involved in will serve the goals I've outlined about lowering barriers to 
entry and providing stepping stones on the path to Chefiness, beyond that I 
think it is antithetical to the idea of Chef being an omni-flexible tool that 
we should avoid these hooks because someone somewhere might make something 
ugly.

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail