A developer goes to a DevOps conference - <AUTHOR> https://www.darkcoding.net/software/a-developer-goes-to-a-devops-conference/ <comment><USER2> This is sadly the state of the current mainstream DevOps "movement". It is no longer anything that could be described as a movement, only as an industry, a set of tools, and a thing a few years back that CTOs in laggard companies announce to the board that they need to be doing.

It was supposed to be about efficiency and repeatability, and approaching ops with a SWE mindset; but most importantly taking ownership of your shit, end- to-end; which is something that the best and most effective SysAdmins and Software Engineers always did.

We don't hire "DevOps Engineers", rather "Platform Engineers", in which we have a hard requirement that you are approaching competence as a software engineer in at least one language, and in at least one paradigm (e.g you should be able to tell me about type systems, data structures, polymorphism, higher order functions, composition vs inheritance, referential transparency, TDD etc).

We also expect that all of our backend software engineers deploy and maintain their own infra (as code), using the guardrails/services/systems provided by our platform team. Deploying a new database cluster for a user-facing service is a pull request from a backend engineer, not a Jira ticket for a "DevOps Engineer"

There are companies out there "doing it right", but they are in the minority.

<comment><USER3> This is something I've been wondering about. I recently interviewed for a full-stack dev position, and I felt I did quite well on all of the _development_ questions. It wasn't a devops role - they had a whole separate devops position - but I got passed over for another candidate and when I got the news it was suggested that I should "get some devops experience" and maybe try again in the future. I thought that was weird. I know generally what docker/containers do and what purpose things like Kubernetes serve, I'd just never used them. I figured I'd be able to pick up whatever I needed for doing minimal devops tasks in the course of the job. Is it common to expect more than that from "developers"? This was neither a small nor a foolish company.

<comment><USER2> I can't speak for how common it is, but in my opinion, it is not unreasonable to ask that developers have at least a reasonable understanding of how the systems that they build actually work, throughout at least the majority of the layers of abstraction that they run upon.

It is though quite unreasonable to expect experience with specific tools, unless you've asked for them on the job spec.

The title "full stack engineer" is a whole other can of worms, not a million miles away from this DevOps thread.

<comment><USER4> I agree with brundolf, these are tools and most people can get a handle on how they work in an afternoon or two. We aren't talking about expecting new hires set this infrastructure up from scratch, just use the tools that are already in place.

</comment></comment></comment></comment><comment><USER5> Over the last 10 years, I've become convinced the idealized notion of DevOps is not a thing. I have a couple reasons:

1\. There is a huge sysadmin workforce. Many of them never learned to really code. Are these people supposed to go away? Are they supposed to learn to code? Coding is a skill that takes time to master, and if these people were sufficiently motivated to code, they probably would've become coders before now.

2\. In general, software engineers aren't thinking about or care about their CI/CD pipeline beyond it being easy to work with. They don't care about their infrastructure except insofar as what they need to know to make their stuff fast. There is a nice separation of concerns there that's nearly impossible to avoid. As a result, it's very easy to build higher order tools to handle most workflows and infrastructure. It's the whole reason AWS can exist and why most devs don't care about the details of ops.

I realize I'm speaking in very broad terms. However, broad terms are what define an industry. I've seen this play out enough times that I knew what this article was going to be about before I even clicked on it. I'm pretty sure most other people did, too.

<comment><USER6> I'm convinced it's driven by business communication and objectives more than skill set.

I've _never_ worked with a "product manager" or "product owner" that could effectively tell me what a SLO was, or simply tell me what the business impact of bugs were. All I usually get is what we'll lose if we don't implement feature X or Y.

This impacts "DevOps" because it almost always puts focus and priority on anything feature-related. In order to do anything not feature-oriented, you literally have to be fighting massive quality problems on a daily basis. Thus... very few organizations understand how to have "devs and ops spend quality time together". Almost all time not building features is wasted in their eyes.

In the end, this is why there's a "dev and ops split". The devs drive features, which PMs understand, and the ops makes things run, and the PO/PM types ignore them but sometimes like to make requests.

I think a pre-cursor to any real DevOps culture are SLOs that are understood and reported to executives. If that doesn't exist, DevOps usually ends up being a BS term used to "remain relevant". Without some kind of business quality objective, real DevOps time is pure cost, and counter to business development.

Just like "agile" BS, any real change usually starts at the top fo the company.

<comment><USER7> I'm not convinced that it's only POs that struggle with quantifying the cost of a bug in production.

I can see the same when programming language advocates extol the benefits of more static analysis for software that does not even remotely need the level of reliability they are aiming for.

The guy who hacks it together in PHP will just get to market first and get such a critical mass of market share that 5-10% more reliability probably won't matter.

Of course a lot of this depends on market sector, self driving cars are a million miles from serving banner ads.

<comment><USER6> True, many POs/PMs drive a lot of prioritization of work, since (maybe unfortunately), they're usually the ones left to "understanding the business impact".

It kind of adds more credence to people not being so siloed in responsibility. We all just bring different skills to the party. Thus, we're all responsible for quality, for business impact and prioritization, etc.

Unfortunately, I've often had situations where, upon a reorganization, I'm left with managers who love to "guard others from distractions" and end up cutting team members off from broader discussions. Thus, leading to the siloing.

This is why I think "DevOps" ends up meaning nothing. It's a _lot_ of details that requires lots of communication and knowledge sharing that can be overwhelming to, ahem, certain PHB types. Sometimes you can implement a tool, other times you can just not build a particular feature, but the reasons are usually very complex and never easily get broken into a simple one-liner task definition with a story point cost.

</comment></comment></comment></comment><comment><USER8> > The most common job title seemed to be SRE (Site Reliability Engineer), > although there was a long tail, and they don't care much about job titles.

Oh I like that one. "I kept the pile of shit running and put the fires out before they were noticed" is too long to put on a business card, anyway. "Site Reliability Engineer" sounds almost tame.

<comment><USER9> The name and job title churn in this space over the past five years is breathtaking, almost JavaScript-ian.

I've been at my current company for 6 years now. When I first started, those guys were "Operations", and the job title was "Admin". We used Google App Engine, and they mostly clicked buttons in the GCP web console.

One year in, they re-branded as "DevOps". They were all "DevOps Engineers". They wrote a lot of hacky Python scripts, using the "gcloud" utility, to manage our new Docker-based services on Google VM's.

A year or two later, they decided to become "Platform Services". They changed their titles to "Platform Engineers". They saw us developers using Jenkins for our CI/CD pipeline, and decided to re-implement all of their Python scripts as Jenkins jobs.

Earlier this year, they became "The SRE Group". They are "Site Reliability Engineers" now. We eliminated their Python scripts, by migrating our microservices to Kubernetes and using managed databases. So now they're back to clicking buttons in the Google Cloud Platform web console again.

<comment><USER10> You speak of them with such disdain. Is that a common attitude in your company?

<comment><USER11> I can understand such disdain. I am a software engineer currently working in a DevOps team (yes, team, you've heard it right). I'd say that 90% of DevOps engineers I've met don't even know what a linked list is, and they themselves talk with disdain about developers.

So much for DevOps philosophy.

<comment><USER12> I wouldn't mind so much if they at least knew what terraform was.

<comment><USER13> _if they at least knew what terraform was_

Any real, experienced DevOps engineer will reply "a steaming pile of shit".

<comment><USER14> Sure, it's got its problems, but please show me a better alternative.

<comment><USER13> On AWS, Boto. On Azure, DSC (Powershell) and ARM templates.

You will need to maintain separate TF codebases for each one anyway, but with the native solutions you get easy access to all features of the platform and don't have to spend most of your time jumping through stupid hoops to try and pretend that one tool can do everything.

No-one would write code worrying if it was valid in both Java and C# but that is the same level as what TF claims to do. It's complete shit, ditch it and you will be 10x happier, I guarantee it.

<comment><USER12> Sounds to me like using a single tool instead of a bunch of separate ones with different functionality is a win to me, but we are each entitled to our opinions.

Boto doesn't seem comparable to terraform at all, unless you enjoy building state management yourself.

Terraform has been better than anything else I've tried so far.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I recently transferred as a developer to a development operations role at a medium-sized company. This article exactly describes my experience - the main focus of the ops team seems to be on build, deployment and monitoring technologies focused on a migration towards containerization running on AWS.

Code and tooling is built on a "what works" basis and no particular attention seems to be paid to the overall design of the software or testing (likely due to a real or perceived lack of time). On-call rotations (and how to eliminate work for them) is the hot button discussion topic.

The #1 question I get asked by the developers is "Did you _really_ want to transfer from development to ops?" which me think that a lot of developers look down on operations roles and see it as a demotion. I find that quite odd given that 1) ops keeps the product up and the money coming in with relatively little headcount and 2) most of the people working on our ops teams have a formal education in software engineering.

<comment><USER16> > The #1 question I get asked by the developers is "Did you really want to > transfer from development to ops?"

I'm not sure what job listings they're looking at, but as an ops person (kubernetes) I'm interviewing for jobs with close to half a million a year in total comp.

<comment><USER17> Second time I'm hearing (what's for me) a mile-high comp number for kube jobs and I'm now really tempted.

Working as a data scientist - software engineer in a midsize company, I constantly battle amateur ops folk and "backend" fullstack jockeys from introducing kubernetes into a saas product I mostly created by myself (makes money but there are maybe ten users per hour tops, why would I need kubernetes for that?).

My org has seen multi-day downtimes for the entire eng team workflow because the eks cluster went down and they couldn't figure out how. We have four people dedicated in the infra team for this! I'm not really an ops person but I see where the failings of these folks and stacks are, and feel like I might be able to learn to be half-decent if I put the time. What advice would you give ?

<comment><USER18> Kubernetes is a full time job. If you want to capture 90% of the benefits of containerization without wasting too much time on a complex solution then simply restrict yourself to only use docker with bash scripts and maybe a load balancer if you really want to have HA.

I've found nomad to have a lower complexity than kubernetes but if you cannot directly integrate service discovery into your application then you will need to use a service mesh which is an all or nothing thing but using something like traefik's support for consul means you will have to use regular service discovery alongside the service mesh. It's not a huge burden but there should be a better way.

</comment></comment></comment></comment><comment><USER19> > DevOps means the veteran admins had to check in their personal scripts

Oh my, this is an epiphany.

I don't even know what DevOps means. But if the implication was that the "veteran admin" was making arbitrary state changes and is now forced by DevOps to document it in the commit history, I am firmly in favor of whatever DevOps is.

<comment><USER20> What it was supposed to be -

Software development, deployment and ops come under the same role. The DevOps engineer controls the horizontal and the vertical, the code, the environment, the build, the deployment, and as such is a multi-talented unicorn.

What it seems to have become - Sysadmins writing scripts around terraform, and formalising their work to the extent that it is at least usually reproducible.

<comment><USER21> > a multi-talented unicorn.

That's not necessary. Natural curiosity and willingness to treat dev/ops (whichever is not your team) as _us_ , not _them_ , is sufficient.

<comment><USER20> I'm not sure I've seen that be any more prevalent now than it was when we had developers and sysadmins.

To me it's become like 'agile' and interesting set of viewpoints and philosophies totally ruined by the industry that's grown around it.

<comment><USER21> Well, at least the DevOps industry brings actual value to the process (well, not when you are sold OpenStack, OpenShift, Vault and whatever else to run a single container image).

</comment></comment></comment></comment></comment><comment><USER22> > Everyone hates YAML. Everyone writes a lot of YAML.

I don't know a single engineer (ops or not) who enjoys writing YAML, yet it is utterly unavoidable.

I've lost count of the amount of bugs and broken deploys that have happened because of YAML, or because of a type error caused by it.

<comment><USER23> Yeah, what I want is JSON with comments and nice multi-line string support. I don't like how much syntactic magic YAML does (I don't need or want the country code for Norway to be parsed as a boolean False value). I still don't know what the exclamation point does (e.g., !Ref).

And clearly YAML is the wrong tool for infra-as-code since CloudFormation has to build a macro system, conditionality, referencing, and a couple different systems for defining and calling functions (templates being one and their implicit functions being another). We also see tools like Troposphere and CDK which are effectively different ways to generate CloudFormation YAML via programming languages (or more precisely programming languages that were designed for humans).

And it's not just limitations inherent to CloudFormation--Helm has long had templates for generating YAML, but those also weren't sufficiently powerful/expressive/ergonomic so Helm3 is supporting Lua as well. And as I understand it, Terraform is constantly adding more and more powerful features into HCL.

So what's the solution? It's pretty simple--we should keep the YAML around, but it should be the intermediate representation (IR), not the human interface. The human interface should be something like a functional language[^1] (or an imperative language that is written in a functional style) that evaluates to that YAML IR layer. The IR is then passed to something like Kubernetes or Terraform or CloudFormation which understand it, but it's not the human interface.

As for the high-level language, something like [Starlark][0] would work well. It's purpose-built for being an evaluated configuration language. However, I would argue that a static type system (at least an optional static type system) is important--it's easy enough to imagine someone extending Starlark with type annotations and building a static type checker (which is much easier for Starlark since it's a subset of Python which is intended to be amenable to static analysis).

This, I think, is the proper direction for infrastructure-as-code tooling.

[^1]: Functional in that it is declarative instead of imperative--not necessarily that the syntax should be as hard to read as OCaml or Haskell. Also, while YAML is also declarative, it doesn't have a notion of evaluation or variables.

[0]: [https://docs.bazel.build/versions/master/skylark/language.ht...](https://docs.bazel.build/versions/master/skylark/language.html)

<comment><USER24> I do not understand the need for all of these different new language implementations and data formats. GuixSD vs NixOS already showed that Scheme is a superior solution as a configuration language, scripting language, template language, and intermediate representation. A single language that has 30+ years of successful production use, tons of books and documentation. Why re-invent the wheel in four different, incompatible ways?

<comment><USER23> Is NixOS a scheme? Anyway, we moved away from Nix because of all its problems (the language being only a medium-sized one). Also, I detest CMake, but by your own standard (longevity, popularity), it is better than Nix or Guix. Frankly those tools haven't shown themselves to be "superior" in any meaningful way. Yes, they have been around for a while, but having been around for a long time and not enjoying any significant adoption is not very compelling.

<comment><USER24> > Is NixOS a scheme?

That question does not make any sense. I am talking about Scheme the programming language: [https://schemers.org/](https://schemers.org/)

NixOS is a GNU/Linux distribution built on top of the Nix package manager. The Nix package manager has its own custom configuration language. GuixSD is a GNU/Linux distribution built on top of the Guix package manager. GuixSD uses Guile Scheme as the package configuration language, system configuration language, scripting language, and implementation language for many of the system services (such as init). GuixSD does more things better with an existing standard programming language than NixOS does with its own custom programming language.

> Also, I detest CMake, but by your own standard (longevity, popularity), it > is better than Nix or Guix.

What does CMake have to do with anything?

> Yes, they have been around for a while

What are you talking about? The first stable version of NixOS, 13.10, was released in 2013. GuixSD 1.0 was only released this May.

Your post is hard to make sense of.

</comment></comment></comment></comment></comment><comment><USER25> I am a solutions architect at Red Hat but I came from being an application architect. I recently gave a talk on cqrs and event sourcing at a midwest user group. I am routinely surprised how few "DevOps" engineers care to grasp application architecture yet want to start dabbling in things like Kubernetes. Automation using Ansible, yes, no problems there. Creating microservice architectures using containers and kubernetes tooling is yet a ways out for many. New tooling is absolutely necessary to implement the things we have all been talking about for at least 10 years. Developers can no longer just care about writing code. They have to think about how to manage breaking up their monolith, not just for performance; that's not typically the driving force behind adopting microservice architectures. It's about improving lead time and reducing the batch size of releases. You can't have microservice architectures without both sides(dev and ops) understanding what each actually do. I have first hand knowledge how difficult it still is to break those silos down. Developers, if you still think writing code is the hard part; well, I've got news for you. Ok, writing good code is still hard but there's a lot more to think about to get the most out of that code when it goes to production. As a starting point to answer "why do any of this?" I recommend the book "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations".

</comment><comment> pi-victor been in an ops role for 2.5 years, 2 years as software dev and currently i'm in a devops role for 2.5 years now. this article hits the nail on the head. this was nothing more than a rebranding of the word ops. it has very little to do with actual software development. not to say that i don't enjoy it, for the better part of the time i was a software dev, i really missed setting up machines and day to day network/system administrator work. i know my way around 4-5 programming languages so i'd say if the need arises i can use the right tool for the right job. however, kubernetes, aws, terraform, packer, ansible, bash, etc are everyday things. i'd say in the last years i've developed a love hate relationship with pretty much every tool out there (looking at you terraform and k8s). the pitfall with this position is that there's a lot of buzzwords flying around and 9/10 and if you have some idiotic management you end up implementing some overkill solution to fix your problems. the other pitfall, from an infrastructure perspective, is that the ecosystem around kubernetes is so big that there are now an insane number of moving parts that you need to maintain and monitor.

</comment><comment><USER26> > Being a gathering of system administrators I'd expected more IRC, there was > no mention of it.

We just don't tell you about it -- Slack is more visible to management, and thus infosec has made slackbots a fucking integration nightmare.

</comment><comment><USER27> > _As a result they also talk about mental health more than programmers do._

It really is. All of the lifelong DevOps/sre people I know have spent time grappling with the consequences of this. On all experiences also seem so much more dramatically in larger companies where teams can properly load balance.

</comment><comment><USER28> > DevOps is Ops with new tools... I did not meet or hear from any developers.

This is awful! It's not DevOps, it's an old infra gathering! Very disappointing.

I expected devops conference to have devs ONLY. Devs that that are curious and passionate about whole product life cycle, hardware, scalability, deployments and networks, devs who also pulled and transformed/transitioned their ops friends into devs.

Is it a general trend with DevOps or just devopsdays Portland conference thing? Is it cargo-culting?

<comment><USER29> > I expected devops conference to have devs ONLY.

In the past five years I've been doing this, I can emphatically say that the number of software engineers/developer types that I've met at DevOps events are so few that I can more or less count them with both of my hands.

In many ways, I consider DevOps an evolution of what systems administrators do. These days, there's so much demand on infrastructure teams to do more with less. Automation systems have massively improved our productivity that the business types are happy to do so much more that it leads to a vicious cycle of compression and stress.

Don't get me wrong, I love automation and such. But it's terrifying that we're asked to put together systems that we can't comprehend.

I'd consider myself an oddball in the "DevOps scene". I was a bona-fide polyglot software engineer before I pivoted. I did embedded systems in C and C++, full stack Java work, Nodejs stuff, etc. I later did QA automation work in Python, and pivoted from that into DevOps. It wasn't that far of a jump.

But most people I know in the "DevOps scene" are nothing like that. They don't have years of experience in OSS allowing them to see the real gold in the pile of fool's gold. They don't have professional experience doing software development. Many of them only barely understand software architectures. Life cycles? Beyond systems maintenance, there's not much for them to learn about.

I would argue that proper DevOps teams wouldn't have things like on-call rotations that give periodic or constant on-job demands, as that's usually an SRE-type responsibility. But DevOps is just a fancy way to reduce your Ops teams for most places.

<comment><USER30> I also moved from development to ops and am now at a company with a large engineering organization.

Most developers don't care about ops. They expect everything to "just work" and they don't expect to have to help that process along with the way their code is written. It doesn't matter how junior or senior they are either.

I'd say more than 50% do things that are extremely irresponsible wrt resource utilization. Especially if it's I/O.

</comment></comment></comment><comment><USER31> I've started my career very early on on the age of 16 as a system admin. Heart and soul was on pure engineering and less on what people label these things on CVs.

A few years later I moved up the stack into a full time programmer and been doing that ever since 20 years down the line.

I have built systems from the ground up literally, loading the van with the equipment, installing the racks, the servers, the EMC's ...

Having seen it from all perspectives, sys admin, DBA, Ops and all it's variants and a programmer. I'd like to think of my self as an engineer who solve problems or build things to solve problems.

The tools that you use does not define you. I have seen and still seeing loads of people Devs who don't understand or willing to understand how ops work Or how the crap they produce runs and get maintained.

And ops who write hacky code in the name of infra as code.

I wish we can just be Engineers and stop labelling and define people by the tools they use. Things will be better IMO

</comment><comment><USER32> "everyone hates yaml" hah. Shocking how we're stuck on these problems.

The old line about "the problem that it solves is not hard and it does not solve them well" about XML is kind of hilarious when we're still facing the same thing about its current popular replacements - JSON and YAML.

<comment><USER33> I'll take _limited_ YAML over JSON any day of the week for things that might be edited by hand. The cleaner diffs when appending to a list alone are worth it.

<comment><USER34> True, but when the YAML file gets long and complicated, such as when a kubernetes YAML spec, it becomes difficult to figure out what indentation different items need to be at and you end up needing to use tools other than just your laptop: [https://twitter.com/Caged/status/1039937162769096704?s=19](https://twitter.com/Caged/status/1039937162769096704?s=19)

<comment><USER32> Hah, I can see my own old response to that tweet.

Anyways, as horrifying as it is, that's actually an argument in favor of XML. After all, would being lost in {} be that much better than indents? You'd still be scrambling to figure out how deep you are in a deeply nested object.

The obnoxious repetition of xml's closing elements actually helps here since you can see _what_ object you're closing.

...

But I hate XML.

At this point I'm fantasizing about using heavily-sandboxed Lua and going fully Turing-complete so when your files are getting horribly complicated you can start doing some minimal reuse.

</comment></comment></comment></comment><comment><USER35> For me the meaning of DevOps has shifted from "developers and operations working together" to "operations picking up developer tooling". As more and more administrators become familiar with the new workflow I expect them to transition from mostly relying on manual testing and scheduled drills to writing automated tests for infrastructure fail-over, backups, firewalls, etc.

I'm not a big fan of YAML the format but I'll gladly put up with it for the valuable content that's encoded in those files - the entire system described in a transparent accessible manner at an abstraction level which enables the developer, the network guy, the server guy, the storage guy, the architect and the security guy to have a meaningful conversation.

</comment><comment><USER36> From the article:

 _DevOps is Ops with new tools. I went to DevOpsDays thinking DevOps means developers and operations merged into one team. I was wrong._

 _I did not meet or hear from any developers. It was a gathering of system administrators who use version control, and write a lot of YAML. Programming languages were not a topic..._

 _DevOps means the veteran admins had to check in their personal scripts, and everyone is expected to automate more things. They relate to the software their business runs ("app", "asset") the way a merchant-navy captain relates to what's in the containers on his ship._

Ah. This must be DevOps for big shops. Not "why are we paying operators when we could have the developers do it?"

</comment><comment><USER37> I'm an organizer for one of the (many) DevOpsDays Conferences held around the world. Speaking only for myself, I struggle with making sure that DevOps is about Dev and Ops working together, not just Ops / SysAdmins using a different, more marketable job title. When Operations Engineers become DevOps Engineers, it subconsciously says to Developers that they don't belong.

I'd encourage all of you that feel excluded, or feel like these are just SysAdmin conferences in sheeps clothing, to go to your local DevOps Meetup and start there. Demand that DevOps continues to stand for a community and cultural way of making software development suck less and not just "the next Agile". /rant over

<comment><USER38> > When Operations Engineers become DevOps Engineers, it subconsciously says to > Developers that they don't belong..

I think anyone who actually feels that way about their peers getting a title- change is being incredibly over-sensitive.

The fact is that for many years, some "System Administrator" types did already think like "developers" and use similar tooling. Those folks just didn't get recognized or paid for that, because the role was defined by what you did (keep things operational), instead of how of you did it. So when "DevOps" became a thing, it was actually not a huge leap for many Operations types. So it's reasonable that many of them found positions with the "DevOps" title appealing due to the increased pay and prestige, and the fact that they already had the skills to do it.

Conversely - many developers don't actually have much experience running production systems, and it can feel demeaning to hear those people say that Operations-types do DevOps "wrong" because operations people don't want to use the latest bleeding-edge tool or the most efficient programming language. A preference for stability and maturity is something learned from experience, and stability happens to be very valuable when it comes to production situations.

All that said, I still love hearing from dev-types who share their experiences around DevOps. Both sides should continue learning, hearing each other out, and valuing each other's contributions without assuming ill-intent or inferiority due to their educations background or previous titles.

<comment><USER29> > The fact is that for many years, some "System Administrator" types did > already think like "developers" and use similar tooling.

The funny thing is that it was the opposite for me. I became a DevOps Engineer because a lot of my work was being self-supported with my own infrastructure. I found that I had a knack for finding and putting together good systems to support my work. In many ways, I guess I was considered the quintessential DevOps person. In my QA role, I wound up being a developer who needed to put together infrastructure to support the needs of the QA group and to a lesser extent software engineers.

When this was recognized, I was moved into the sysadmin group as a founding member of a new team. That team grew and split out into its own group that specifically interfaced with both software engineers and infrastructure engineers. My team is not perfect, but it's been the best I could ask for. We've done amazing work transforming our engineering processes over the years, and software engineers are now more often part of the infrastructure bringup process than not. We've still got a ways to go, but we're getting there.

</comment></comment></comment><comment><USER39> I find this article to be a little frustrating. It is kind of like a layperson going to a mechanic convention and saying "all I heard about was engines, brakes and tires. Everyone is interested in tires".

If you are not in the domain, then you will not understand why the 'devops' engineers are all looking at these things. Kudos to the developer for going to the conference and learning something new.

Devops are exactly the same as Software Engineers. There are those people that just slap code together and do not care about design, tests or the longevity of the product. Devops can be the same where they just push the button in AWS, create some bash scripts and get things running.

Then you have those Devops that approach building product and infrastructure in a repeatable, scalable, traceable fashion. They care about software engineering practices and building something to last.

I work as something in between a platform engineer and ops. I run 4 kubernetes clusters in GCP, had to build up all the underlying resources (dbs, service accounts, storage, clusters) and get the product running on it. I use terraform for this, including kubernetes deployments, and it works quite well.

Just like software engineers, devops/ops is under time constraints and have to hack things together. Whatever it takes to keep the business running...

</comment><comment><USER40> > The most common job title seemed to be SRE (Site Reliability Engineer)

This article (plus the comments) kind of scares me because I am a CS student who just received an opportunity to work as an SRE Intern at a pretty big company over the next summer break. I took it because I wanted to find out whether SRE is a role for me but I am a bit worried that if I accept a more permanent SRE role after the internship, will it hurt my chances of moving to dev role later in my career.

<comment><USER41> My job is 50% dev 50% devops/sre i would say.

One thing I noticed about whole SRE/devops scene lately is that there seems to be no grasp of the KISS principle, there are people building elaborate glass houses on top of k8s (tho k8s+pipelines is very useful its easy to get carried away)

another observation is that the people who are not good programmers but are good at appearing to get stuff done (but who create tons of tech debt) seem to fall naturally into SRE roles, as there is no testing culture in pipeline driven development

SRE currently is like the wild west, it be many years before it starts to resemble engineering

<comment><USER42> This. I run opsZero and the amount of CI/CD implementations I see in different infrastructures is crazy. Most code is not tested or overtly complex and every DevOps person seems to reinvent the wheel a hundred different ways.

Living in the world of Terraform, Kubernetes, and helm has been a godsend because it codifies deployments into a few buckets that removes a lot of this custom code. To be honest I'm thinking the days of DevOps may be numbered.

</comment></comment></comment><comment><USER43> Its hilarious to read Developers and Operations guys bash each other with DevOps.

DevOps is about getting those two groups in harmony where they compliment each other.

Nothing else.

</comment><comment><USER44> You have a monolith. The monolith is deployed by a grumpy old admin using a shell script. He monitors it with another shell script. This is the old, bad way of doing things. Monoliths are bad because they are the kind of thing only neolithic cavemen would care about. So you break up the monolith into micro- services. Of course, you use (other) services to provision and monitor your new micro-services. You now have dozens of tools and scripts and configuration files. This is, naturally, the modern way of doings things. If tomorrow morning, your 500 customers suddenly become 3 million customers, you can just flip a switch and scale on demand in the cloud! Soon you'll be so successful that you can even hire an entire team to look after your new non-monolithic system.

<comment><USER45> It's soon time to invent nano- and pico-services, so everything gets to be scalable by default. That way we can finally stop bothering about first examining the problem domain at hand, and pull out all the stops at once -- looking busy like bees in the process.

Excuse me while I construct this house from micro-bricks and molecular mortar first.

</comment></comment><comment><USER46> I've always "automated stuff away" and worried about making sure whatever I developed had a sane, reproducible way of a) being tested and b) being deployable at scale, so I've watched DevOps/SRE unfold as I hopped between both sides of the fence (I'm a Solution Architect at Microsoft now, and spent a few decades in telcos doing the above).

I'm going to be (intentionally) critical here, but please understand that these are examples taken from a biased sample (I work in Portugal with very traditional enterprise customers and early stage startups, either of which usually lack-or don't care about-senior talent - juniors of all stripes tend to be over-enthusiastic about jargon and bleeding edge, and the blast radius is huge on both kinds of companies).

The way I see it (in both enterprise and the local startups I deal with) is that DevOps has created as much confusion and undue ceremony as Agile in many places, all of which share a common trait—developers there do not understand (or want to deal) with software architecture and just want to hit their sprint targets without reasoning about the architectural impact of implementation details.

Enterprise devs will usually not have any real control about architecture, internal endpoints or even dev environments (all the Ops is taken away from them) and startup devs are usually rushing things, setting up faster infra to fix code problems and building up technical debt _in architecture terms_ (the Ops stuff is usually haphazard and too bleeding edge).

There are some positive exceptions, though. I'm currently helping a customer do Kubernetes from a _governance_ perspective (i.e., figuring out all the steps from dev to prod including environments, namespaces, network policy groups, etc.), and even though this is being done alongside already existing deployments, _taking the time to plan and work things out inside your org_ makes a lot of difference.

We're not calling it DevOps, SRE, or Agile. It's not a buzzword-laden, Valley- anointed process. It's just (senior) engineers (Devs and Ops) talking and systematically going through what will work and won't...

</comment><comment><USER47> It occurs to me that DevOps is Plato's Cave. So many people think they know what DevOps is, yet all they really know is what they've always been familiar with, and they can only interpret it based on that. It's kind of depressing.

<comment><USER48> Reminds me more of the blind men and the elephant: [https://en.wikipedia.org/wiki/Blind_men_and_an_elephant](https://en.wikipedia.org/wiki/Blind_men_and_an_elephant)

</comment></comment><comment><USER49> A question to ponder: is devops a niche created by developers who can't sysadmin, or sysadmins who can't code?

"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

</comment><comment><USER50> > DevOps is Ops with new tools. I went to DevOpsDays thinking DevOps means > developers and operations merged into one team. I was wrong.

Nope, he was right. DevOps is all and only about removing the wall between Dev and Ops. That might go as far as merging the team, but not necessarily.

However, the conference is _dead wrong_ is they convey the feeling that "DevOps is Ops with new tools". That's akin to putting lipstick on a pig, and does DevOps as an organization tool a lot of wrong (just like Agile, etc.).

</comment><comment><USER51> DevOps is about collaboration between devs and ops towards building software and operating it efficiently to meet business needs. Traditionally building and operating were looked very differently but experience has taught us that features and stability cannot be achieved without understanding of how features were built and what needs to be done to run those features in production efficiently. In an ideal world, the same person should be able to build and operate systems in production however we don't live in an ideal world - traditionally there was a big divide between devs and ops, and in complex environments you can't learn to do everything yourself. Hence... DevOps.

There are multiple ways this can be achieved. This article is a good read to understand different models of implementation of DevOps culture - [https://web.devopstopologies.com/](https://web.devopstopologies.com/)

"DevOps is Ops with new tools. I went to DevOpsDays thinking DevOps means developers and operations merged into one team. I was wrong." \- This is kind of right but not completely. DevOps is about bringing ops closer to dev teams by either merging ops or retraining devs to be able to be better at ops (there are more ways as indicated in the above article about DevOps topologies). The idea of doing ops with new tools is that these new tools help us with doing ops like we are building software. Many software development best practices, abstractions, architectures can be now applied to ops as well. This shift in doing ops with these tools which are a lot like other software development tools enable ops to come closer to devs and vice-verse. Here is a great talk by Mitchell Hashimoto (the creator of Terraform, Packer, Vagrant, Vault, etc.) that got me into DevOps - [https://www.youtube.com/watch?v=UTQQggVx4sI](https://www.youtube.com/watch?v=UTQQggVx4sI). This talk explains the use of tools with the backdrop of DevOps.

Other than these two things, your observation was spot on. I was not at the event but that's the story at most DevOps events.

I think software architecture will soon become an area of focus in DevOps circles as the right architecture also essential for achieving CI/CD, agility and DevOps.

Never the less, welcome to the world of DevOps. :)

</comment><comment><USER52> The DevOps movement petered out because it solved most of it's technical problems with tools that have become industry standards.

As a sysadmin, you used to have to write scripts to solve EVERYTHING. Especially since tooling for ops people in the 2000s was a load of hot garbage. A lot of tools back then had GUIs, which weren't automation friendly.

Nowadays most ops problems have some easily automatable tool, which I think gives less incentive for sysadmins to reach for a programming language.

<comment><USER45> It seems more likely to me that those "devops tools" only solve a small slice of the big sysadmin cheese, and not in a flexible way (one useful skill of sysadmins is being able to react on the spot to what's coming to them at that moment, using basic tools and logical reasoning, much like a firefighter).

Being able to differentiate between what's worth to automate and what is not is another one of those useful skills. Knowing a scripting language to glue those basic tools together is too. Being proactive (assisted by monitoring software and knowledge of the underlying systems so you can tell what consequences some event have) is another...

None of that is new nor surprising to sysadmins. It might sound fresh to others, being trapped to reinvent a small slice of it (badly). Also, "devops" is just another funky management fad by now.

</comment></comment><comment><USER53> As a lazy developer I enjoy DevOps principles. First time I don't have infrastructure issues. My code builds and deploys automagically and sys-admins can focus on important stuff.

I'd also like to describe it as just another tool in my toolbox. Created by admins for developers. I don't mind YAML at all. It's better than JSON or XML and it's a first class citizen in Go, Python, JS and other languages.

</comment><comment><USER54> Can anybody give me a reason why containers are popular for production deployments (NOT referring to K8 use-cases)? As a development workflow they're amazing - but cheap cloud based VPSs + Ansible/Puppet work really nice. Why would you add another layer of abstraction in there when all it does is hinder performance?

<comment><USER55> Because you are deploying a single artifact with minimal dependencies that behaves in a known fashion.

Whereas if you are deploying code blobs they start depending on the operating system to provide stuff. You have to have the right version of Ruby on each machine. This becomes a problem when the right version varies between products and you would also like to update the OS to something new.

With containers the application code is decoupled from the operating system.

<comment><USER54> Yea I get that. To me this scenario gets mitigated with due diligence checking when spinning up a virtual machine - but I recognise the benefit in having a single artifact.

</comment></comment></comment><comment><USER56> I've been on both sides of that fence for 13 years now (currently in a really nice dev job.).

To me it seems like things are getting better. Often devs and ops are the same kind of people only on different teams, or even embedded in the teams. Nobody is hiding anything and people are working together if stuff breaks.

</comment><comment><USER57> >> Many were curious about service-meshes (basically a smart network proxy?) such as Istio or Linkerd, but almost none were using one.

Going to blame Ubuntu's psychological priming via ads in their MOTD for this one

<comment><USER58> What ads are in Ubuntu's MOTD and what do they have to do with Istio/Linkerd service meshes?

<comment><USER59> Ubuntu's MOTD displays dynamic ads and at least one of these ads was about Istio. E.g. as best I can tell, every Ubuntu installation that hadn't disabled dynamic MOTDs displayed this Istio ad for most of August: [https://bazaar.launchpad.net/~ubuntu-motd/ubuntu- motd/trunk/...](https://bazaar.launchpad.net/~ubuntu-motd/ubuntu- motd/trunk/revision/68?start_revid=70) .

(Of course as a Linkerd person I think it's ironic to advertise Istio on MicroK8s because Istio is anything but micro. But Microk8s has great Linkerd support these days, so maybe we'll get a Linkerd ad one day, and harmony in the universe will be restored.)

</comment></comment></comment><comment><USER60> Spot on. And totally depressing. Apps as black boxes. Ugh.

<comment><USER61> This has been my lived experience with DevOps since I was first subjected to it ~2014. In a word, depressing, yes.

I've been fighting to maintain full control over a few of my teams applications, because I refuse to let the juniors and intermediates, who weren't lucky enough to gain full-stack experience, live in a world where they don't understand how these applications and services, etc..., _actually_ operate in production environments. But I'm losing ground all of the time. Management, emphatically, _does not care_.

</comment></comment><comment><USER13> I can imagine it the other way round: "hey have you tried that new javascript framework? It only came out last week, it's pre-alpha but I already have it running in production. What? No, not a problem, I just chuck it over to ops and they keep it running".

<comment><USER62> You are exaggerating to make a point, but... what else would you prefer? That your sysadmins approve your frameworks? How detailed would you get? Do you want a formal approval cycle before installing a new npm package?

I'd prefer an ops team that trusts the dev team is competent, and trusts that if the tests pass, the devs probably made acceptable decisions.

<comment><USER63> > I'd prefer an ops team that trusts the dev team is competent, and trusts > that if the tests pass, the devs probably made acceptable decisions.

You don't need anyone to _trust you_ as long as you're responsible for deploying, monitoring and responding to failures regarding the app, meaning: being on-call for the app(s).

<comment><USER62> Have you worked in a place that has a dedicated DevOps team, but makes the devs be on-call for the apps?

<comment><USER64> I work (and have worked for nine years) at a company with a dedicated DevOps team. As a developer, I have _never_ been on call, but I do have to be there for deployment of my code to production (which, due to the nature of the code, happens around 2:00 am my time) to ensure everything is working as expected (and only once was a roll back required).</comment></comment></comment></comment></comment>


Ask HN: Android Weekly Job Postings - <AUTHOR> Hi.  We`re building a new Android team. Has anyone successfully hired someone (or found a job) through the Android Weekly news letter? Are there other good android-specific job boards worth posting to? <comment> zupa-hu Weird - why does this not show up in the Ask HN section? Or is it just me?</comment>


Living in a Wheelchair – Scientist/Entrepreneur Living with ALS on Twitch - <AUTHOR> https://www.twitch.tv/livinginawheelchair <comment><AUTHOR> He also has a blog post explaining his intentions [https://firstname.lastname@example.com/rethink-technologies- our...](https://email@example.com/rethink-technologies-our-future- plans-11f106d62bd1) . His mission to create 40 patents and try to turn them into reality within the next year, and if they don't go anywhere, they become public domain.</comment>


Online Business - <AUTHOR> How can solopreneurs build a business online? <comment><AUTHOR> Amm, so this is gone.</comment>


Easy Bookmark of Hacker News Links - <AUTHOR> http://vijaydev.wordpress.com/2009/08/02/greasemonkey-script-2/

<comment><USER2> I used to bookmark HN links but I never went back to them. Now I actively prevent myself from bookmarking and I am finding that I am learning a lot more and spending my time on HN reading rather than just lurking, refreshing and skimming comments.

</comment><comment><USER3> Nice work, but I can already do this by right clicking on a link, then select 'bookmark this link'. You don't need to open the page first.

</comment><comment> onreact-com Wow, that's a super neat solution. Thank you!</comment>


The CIA's Infamous, Unsolved Kryptos Cryptographic Puzzle Gets a 'Final Clue' - <AUTHOR> https://www.vice.com/en_us/article/3a8k93/the-cias-infamous-unsolved-cryptographic-puzzle-gets-a-final-clue <comment><USER2> > Cryptographers who have tried to decode the sculpture told Motherboard that > his code differs from many cryptographic schemes because it has artistic > elements that can't be solved by mathematical decryption methods, which are > more common in the space.

Never roll your own crytpo, except sometimes ...

</comment><comment><USER3> This article has been submitted four times in total. This is the fourth attempt in four days.</comment>


Ask HN: Is there any reason why startup accelerators are not online? - <AUTHOR>

There are no any online ones, right? But why not? <comment><USER2> 65% of human communication is nonverbal. If I'm giving you >$10k I want to meet you in person. Its very easy to lie on a keyboard.

<comment><AUTHOR> But accelerators are not only about money, aren't they? How about a process of looking for co-founders, learning... Video chats may be used for a better communication. At least, online model can be combined with the classical accelerators. What do you think?</comment></comment>


Functional Programming in Python [pdf] - <AUTHOR> http://www.oreilly.com/programming/free/files/functional-programming-python.pdf <comment><USER2> Even knowing a lot about FP, I still found this worth skimming for the esoteric Python syntax. When it comes to constructing dictionaries with list comprehensions, I would always do something like this:

      dict([n, 2 ** n] for n in range(5))

But they pointed out an actual "dict comprehension" that I didn't even realize existed:

      { n: n ** 2 for n in range(5) }

And there is a similar "set comprehension":

      { n ** 2 for n in range(5) }

Always amazes me how you can use Python for so many years and still encounter new features in the language.

<comment><USER3> This is part of the generalized comprehension syntax. You can also do lazy generator comprehensions.

        a = (i for i in range(10) if i % 2 == 0)
        print(list(a))

You can omit the parenthesis, and use them in calls which expect an iterable.

        b = max(i for i in range(0, 10) if i % 2 == 0)
        print(b)

<comment><USER2> It's not exactly the same, which is what I thought was interesting. My first example did use a generator expression inside the dict() constructor, but in that case you need to specify the key and value in a tuple or a list.

With the dictionary comprehension you can just separate the key and value with a colon, which is more natural. It might just be sugar on top of a generator expression but it is definitely a special case, syntactically speaking.

<comment><USER4> Yes, in Python 2.7 onward:

      s = {i**2 for i in range(10) if i}

and the colon is what makes the dict comprehension different from the set comprehension:

      d - {i:i**2 for i in range(10) if i}

</comment></comment></comment></comment><comment><USER5> Nice, short little book!

`compose` can be simpler:

        def compose(fn, *fns):
            def _composer(f, g):
                return lambda *args: f(g(*args))

            return reduce(_composer, fns, fn)

This little function is really, really cool because it allows you to build up more interesting functions by piecing together a bunch of small, useful ones.

        def upper(s):
            return s.upper()

        def exclaim(s):
            return s + '!'

        # instead of this
        really_angry = lambda s: exclaim(exclaim(upper(s)))
        really_angry('napster bad') # NAPSTER BAD!!

        # we can do this
        really_angry = compose(upper, exclaim, exclaim)
        really_angry('fire good') # FIRE GOOD!!

        # and
        import operator as op
        from functools import partial as p
        max(map(compose(p(op.add, 1), p(op.mul, 3)), (1, 2, 3, 4)))

`compose` is a neat function and worth exploring. This is a cool book and I always hope Python gets more light shone on its FP-friendly features.

<comment><USER6> For compose to really shine, you need to be able to curry/partially apply functions. This part of things is made much more difficult than necessary because of Python's unnecessarily neutered lambda syntax (in fact, I don't think one can claim that Python is FP friendly until this decision is corrected).

It's also worth noting that reduce() was removed as a builtin for Python 3.

<comment><USER7> I'd love let-like syntax in lambdas, something along the lines of

        lambda x: f(y) + g(y) for y = expensive_computation(x)

In Python 3, `reduce` can be trivially imported from `functools`.

<comment><USER8> The ugly hack around this would be

        lambda x: (lambda y: f(y) + g(y))(expensive_computation(x))

</comment></comment></comment></comment><comment><USER9> Funny how things turned out. I still remember this post[1], it was profoundly disappointing to see Guido's way of thinking. Much of the damage was reversed but it still left an indelible impression that there's a lack of vision for what's going to be important if the language is to stay relevant in the future.

[1] [http://www.artima.com/weblogs/viewpost.jsp?thread=98196](http://www.artima.com/weblogs/viewpost.jsp?thread=98196)

<comment><USER10> I actually find his arguments rather convincing, even though I'm partial to a functional approach to programming, myself.

<comment><USER11> Some are still pretty bullshit though.

> Why drop lambda? Most Python users are unfamiliar with Lisp or Scheme, so > the name is confusing

To which I'd reply: Why drop class? Most Python users are unfamiliar with C++ or Java, so the name is confusing.

<comment><USER12> Are they? I'd probably argue just the opposite, that most python developers are very familiar with C++ or (most of them) Java.

</comment></comment></comment></comment><comment><USER13> [https://en.wikipedia.org/wiki/Python_Bridge](https://en.wikipedia.org/wiki/Python_Bridge)

"Python Bridge, officially known as High Bridge, is a bridge that spans the canal between Sporenburg and Borneo Island in Eastern Docklands, Amsterdam. It was built in 2001 and won the International Footbridge Award in 2002. The bright red bridge spans 90 meters and was designed by Adriaan Geuze of the architectural firm West 8"

Coincidentally, Amsterdam can be considered the birthplace of Python, where Guido used to work at the Center for Mathematics and Computer Science (CWI).

And now for some obligatory functional python. Run with

        python lambda.py 2>&1 | head -c 200

to avoid filling your screen with exhausted recursion depth. Notice any pattern in the output?

        import sys
        def c(j,t):
         sys.stdout.write(j('.')('P'))
         return t
        (lambda z:lambda y:z(z(y(lambda p:lambda n:(lambda s:lambda z:z(lambda x:
        lambda y:y)(lambda d:p(s)(y(s))(d)))(lambda x:lambda a:lambda s:lambda p:
        p(a)(lambda y:s(n(x))(y))))(lambda c:lambda a:lambda s:z(lambda y:s(c)(y)
        ))))(y(lambda p:lambda b:lambda t:t(c(b,p)))))(lambda s:lambda p:p(lambda
        x:lambda y:x)(s))(lambda f:(lambda q:q(q))(lambda x:f(lambda y:x(x)(y))))

<comment><USER3> This reads like Lisp.

<comment><USER4> Yes it's quite possible to write obfuscated Python. See the docs:

[https://docs.python.org/2/faq/programming.html#is-it- possibl...](https://docs.python.org/2/faq/programming.html#is-it-possible-to- write-obfuscated-one-liners-in-python)

</comment></comment></comment><comment><USER14> It's becoming more common to see "Functional Programming in X". Why don't we use functional languages like oCaml or Haskell more often? Are we making the jump in two steps instead of one? I've never written more than a few lines of either so I can't tell if something "better" is waiting for me in functional land.

<comment><USER15> I'd go one further.

Why are there so very few programs written in say, haskell, that you actually want to use?

This is a serious question that I haven't found the answer for. Around here people suggest pandoc, shellcheck and sometimes the xmonad window manager as pretty much the full list of things you can install, use and hack on written in haskell whose purpose isn't writing haskell code.

Given the popularity of haskell amongst hackers and the various claims about its benefits and strengths, the fact this list is so small (if it's larger and I'm missing a bunch - please DO let me know, I want to play with them and hack on them!) Is something I have difficulty reconciling with haskell being a useful general purpose programming language. Maybe they're being written now and they're on their way? But haskell has been around for more than a few years now. Maybe haskell hackers just mostly hate open source & free software unless it's GHC or a general purpose library? Seems unlikely. So maybe something else I don't yet understand. It is puzzling when I don't code in the language fluently enough to understand its weaknesses as opposed to my own in coding in the language and it's a point the many lovers of haskell never seem to address other than with extreme defensiveness which kind of misses the point of the question.

<comment><USER16> > Why are there so very few programs written in say, haskell, that you > actually want to use?

I think a big part of it was struggling with cabal hell. I know that quite a bit of web development and API stuff is happening with Haskell since I've gotten paid to do some for multiple clients (some requesting Haskell).

I think that with the release of stack[0] (and it eventually being merged into the Haskell platform IIRC) many application developers will start to pick up Haskell and create those types of programs.

Not open source, but an application created in Haskell was bump[1].

0: [https://github.com/commercialhaskell/stack](https://github.com/commercialhaskell/stack) 1: [https://www.fpcomplete.com/wp-content/uploads/Bump-case- stud...](https://www.fpcomplete.com/wp-content/uploads/Bump-case-study.pdf)

</comment></comment></comment><comment><USER17> Yeah. Python has the functional programming features I expect of any modern language. However, I feel that Python has a lot of unneeded syntax. I always prefer apply() over * and map() and filter() over list comprehensions.

        func(*args)
        apply(func, args)

        [func(a) for a in collection]
        map(func, collection)

        [a for a in collection if func(a)]
        filter(func, collection)

I don't see why people use all of this special syntax.

<comment><USER18> In Python3, you are really looking at...

        (func(a) for a in collection)
        map(func, collection)

as equivalent. If you want a list (and not a generator), you would need to do this:

        [func(a) for a in collection]
        list(map(func, collection))

For me, the first set (comprehensions) of notation has a more mathematical feel to it, i.e. { x^2 | x \in 0...10 }. Just replace the bar with "for" and it's almost the same thing.

I believe the documentation for `filter` even mentions that it is equivalent to the comprehension[1].

[1] [https://docs.python.org/3/library/functions.html#filter](https://docs.python.org/3/library/functions.html#filter)

<comment><USER19> I've always found the list comprehension harder to read for non trivial examples. It may just be a matter of which a person learned first.

<comment><USER20> > It may just be a matter of which a person learned first.

I think this is the case, for me _map_ is much harder to read. But I also think that comprehensions go back to math sets, so I was familiar with this even before learning any programming. Therefore comprehensions clicked immediately for me and it's by far my favourite python feature.

<comment><USER6> I learned both around the same time, but even in good functional languages like Haskell, using a comprehension for anything more than simple problems results in an unreadable mess.

map or filter are much easier to read for complex data manipulations and as a bonus, their composition rules make it easy to increase performance. For example, if you see two map functions together, you can wrap them in a compose and only map over your elements once. This isn't as immediately obvious when you're using comprehensions.

<comment><USER20> Could you give an example?

Do you mean something like

> [ manager.name for manager in set([ person.manager for person in employees > ])]

?

I assume with something like set() or unique() you need to create the intermediate iterable anyway, but without it I have trouble finding an example where doing a single list comprehension wouldn't suffice.

</comment></comment></comment></comment></comment></comment><comment><USER21> Hard to tell from a quick scan, but it appears to be slightly more informative than the classic document in the python docs: [https://docs.python.org/dev/howto/functional.html](https://docs.python.org/dev/howto/functional.html)

<comment><USER22> Just in case, a few years back I've seen an article on functional programming in python. Mostly arithmetic but the patterns were very pretty (think Euclid algorithm generalized). I never managed to find it again. If that rings a bell to someone, I'll be forever virtually indebted.

\- [http://www.ibm.com/developerworks/library/l-prog/](http://www.ibm.com/developerworks/library/l-prog/)

\- [http://kachayev.github.io/talks/uapycon2012/#/](http://kachayev.github.io/talks/uapycon2012/#/)

\- [http://anandology.com/python-practice-book/functional- progra...](http://anandology.com/python-practice-book/functional- programming.html)

\- [http://maryrosecook.com/blog/post/a-practical- introduction-t...](http://maryrosecook.com/blog/post/a-practical-introduction- to-functional-programming)

\- [http://rosettacode.org/wiki/Numerical_integration#Python](http://rosettacode.org/wiki/Numerical_integration#Python)

<comment><USER23> Don't think this is the one you're thinking of, but I do like Mary Rose Cook's intro to fp using Python:

[http://maryrosecook.com/blog/post/a-practical- introduction-t...](http://maryrosecook.com/blog/post/a-practical-introduction- to-functional-programming)

<comment><USER22> Indeed, this is quite newer, and a gradual introduction to FP idioms (with good successes).

Mine wasn't introductory and just threw out ways to decompose the problem into counter intuitive (think ~monad) blocks.

I'll edit my post to list those I've found so far. Thanks a lot anyway.

</comment></comment></comment></comment><comment><USER24> Use mochi if you really want to use FP in python.

[https://github.com/i2y/mochi](https://github.com/i2y/mochi)

<comment><USER25> Interesting, thanks for the link. Do you know if it has any multicore (i.e. parallel) support? I looked but all I could see was support for concurrency.

<comment><USER24> For parallel programming, you need either:

[https://docs.python.org/dev/library/multiprocessing.html#mod...](https://docs.python.org/dev/library/multiprocessing.html#module- multiprocessing.pool)

or

[http://www.parallelpython.com/](http://www.parallelpython.com/)

or use the GPU using many available libraries.

</comment></comment></comment><comment><USER26> For anyone wanting a quick intro to fp in Python I stumbled into this awesome presentation (50 slides) about Functional Programming in Python. I especially like his short but clear examples: [http://kachayev.github.io/talks/uapycon2012/#/](http://kachayev.github.io/talks/uapycon2012/#/) . Good intro before getting deeper into the linked book.

</comment><comment><USER27> FP Library in Python: [https://github.com/kachayev/fn.py](https://github.com/kachayev/fn.py)

</comment><comment><USER12> Mostly OT, but I like the short form books oreilly and packt are producing. I never liked the trend in technical books where every single one had to have 6 chapters of language tutorial, etc.

</comment><comment><USER28> I am curious why lists do not have ".map" and ".filter" methods? IMHO it would be so better for chaining, now using a few maps and filters is inconvenient and looks unreadable. Plus, something shorter for "lambda"...

It's one of not too man aspects, where I prefer JavaScript (especially ES6) to Python.

<comment><USER29> That would require any new container classes to implement each of those methods again (and will probably still lack useful ones, like groupby) whereas currently they can just implement iteration and get the rest for free.

You could have both approaches, but that would go against one of Python's core principles ("There should be one-- and preferably only one --obvious way to do it.").

</comment></comment><comment><USER30> Functional programming? In a language with _no tail calls_ and no function expressions?

I mean sure, you can do it, but you'd have an easier time in a language which supports those.</comment>


Is it possible to hack admissions for the CFR? - <AUTHOR> http://www.cfr.org/about/membership/

<comment><AUTHOR> I wonder if there is even a single hacker in the group... we could use some more representation among the world's scarily influential decision makers.</comment>


Ask HN: How to market a Video Dictionary - <AUTHOR>

Hi guys,
Need your advice . Recently launched a new site - http://www.megavocab.com - Its a Video Dictionary.
I am confused about the best way to market the site. It is clearly not a SEO play since the competition is sites like dictionary.com , merriam-webster , thesaurus.com which are long established , more so this site is video something that google does not understand completely when compared to text
I am trying to hit facebook and twitter to get some traction but that is a tad slow ...
Any suggestion how can reach a relevant target market in a scalable way ? <comment><AUTHOR> Any suggestions guys ??? will help a lot ...</comment>


Show HN: Screen-clean: automatically clean up screenshots from your Mac Desktop - <AUTHOR> https://github.com/ryanatallah/screen-clean <comment><USER2> Thanks. I'm doing this manually every few days and have so far about 1300 screenshots in that folder. It's a simplest possible way to keep a diary if you spend most of you time on a computer.</comment>


Both Gmail and WhatsApp have now passed more than 1B MAU - <AUTHOR> http://9to5google.com/2016/02/01/gmail-whatsapp-billion-monthly/ <comment><USER2> The difference is that 1BB active uses means (potential) ad revenue from 1BB users as opposed to 1BB "active mind share' for Whastapp. Zuck, has yet to come with some way to monitise the headcounts.</comment>


Ask HN: Calculating the Operating Liquidity for Lotteries - <AUTHOR> Hi there,
Does anyone know how lottery, gambling, or games of chance businesses calculate the operating liquidity they need to keep reserved on a daily basis in order to pay out winning games?
I'm leading a team doing academic research on the Hot Hand Fallacy (HHF) prevalent in number selection for games of chance. We are specifically looking at lottery games, and in some of the real world data we're working with, HHF can considerably skew number selection towards "streaking" numbers (when the same number repeatedly wins across drawings). In unique circumstances, HHF can cause a significant spike in player selection of these numbers, causing a highly disproportionate liability to the lottery operator.
While research on HHF and other types of phenomenon are still being studied, it seems likely that the businesses operating these games necessarily account for events like these in keeping cash reserves to cover returns-to-player.
Does anyone know how these businesses calculate their operating liquidity needs, and if so, do they account for events like this which skew the probability of the games they are offering? <comment><USER2> There's special reinsurance for providers. [https://www.lottery- insurance.com/lotteries.html](https://www.lottery- insurance.com/lotteries.html)</comment>