Hacker News Reader

Comment by hintymad | Hacker News Reader

> "You'd be surprised how many people get turned off by seeing something that other people tell them is simple, and then it's not simple to them."

This. This should be every platform/infrastructure engineer's motto. Don't tell me your DSL is simple. Don't tell me that Puppet is so simple because oh my god, it uses Ruby. Don't tell me that HCL or terraform or whatever yaml crap is so simple because "they are in yaml". No. They are not.

Don't. Make. Me. Learn. It's not because I don't want to learn. It's because I want to learn fundamentals instead of your specific, non-generalizable, 6-month-or-less half-life stuff.

View on HN

My sophomore calculus Prof, whenever he'd introduce a new concept he'd say "ees treeveeal!" It was a such a trademark that the students would keep a log in their notes of every "ees treeveeal!". (Of course, the joke was none of it was trivial.)

One day, he remarked that this new concept "ees non-treeveeal". We knew we were in for it then!

My jet engine Prof would lay out the boundary conditions of a problem. Then, "Und now zat vee haff zee eekvayshuns, vee merely turn zee krank!"

What can I say. I enjoyed those classes very much.

This gives me flashbacks to undergrad engineering courses. Nearly none of my professors, at a top 10 electrical engineering program, were able to explain things very well. Then you'd have to dive into poorly written textbooks to figure out what was going on. Kids these days have no idea how good things are with lots of youtube videos and online tutorials that give clear explanations for how things work. Even then, I noticed my old engineering program is still managing to fuck things up by doing things like using synthetic, poorly documented fictional microprocessors to teach assembly and computer architecture.

I have no idea why someone would want to teach with a fictional microprocessor.

[I'm well aware of who I am replying to here, I'm merely taking the bait and providing some hopefully fun links for people to dig into. :)]

Because that's how Professor Wirth ¹) does it ²), because it allows for some interesting educational side-treks ³), and because the difference between a fictional and real microprocessor is smaller than some might think ⁴).

¹) https://people.inf.ethz.ch/wirth/index.html

²) https://people.inf.ethz.ch/wirth/CompilerConstruction/index....

³) "So what instruction would you add to this CPU to make the work we've been doing easier? Great, implement that instruction in the provided emulator."

⁴) https://people.inf.ethz.ch/wirth/FPGA-relatedWork/index.html

(edit: And, of course, there's FPGA implementations of Professor Knuth's MMIX (http://mmix.cs.hm.edu/), too: https://github.com/tommythorn/fpgammix)

Yeah, well, I learned on a real 8 bit microprocessor (6800). It has about 40 instructions, all are simple. It's quite a dopamine hit to run your first program on an embedded system and see it working. It felt like being Master of the Universe!

(FPGAs did not appear for another decade.)

Khan Academy was my teacher

I had a freshman year calc professor who also loved to label lots of concepts as “trivial.” It became a meme in my friend group. Unfortunately for my GPA, it was extremely nontrivial for me — I was only saved by a (nontrivial) amount of eleventh hour effort to absolutely smash the final.

My maths teacher used to finish his proofs with QED - which he said stood for Quite Easily Done! My latin teacher was not so convinced...

> Don't. Make. Me. Learn. It's not because I don't want to learn.

I disagree. I. Don't. Want. To. Learn.

Almost nothing in between me and getting my problem solved is interesting nowadays. Everything I have to learn is just another yak I have to shave in between me and getting my problem solved. This is doubly irritating when the yak is infrastructure (configuration systems, build systems, source control systems, etc.) that has zero bearing on my problem.

Here was one: "We want to add audio to our phone app." GROAN.

App is in Flutter on Android which implies:

1) Flutter

2) Dart

3) Gradle (dear God, help me)

4) Groovy

5) Oboe (for sound on Android) implying

6) Android NDK

7) CMake (hey Satan, I'll take your help too)

8) C++

And I'm leaving out a bunch of stuff. And there will be even more for iOS.

NONE if this is interesting to me. Only 2,5 and 8 are directly applicable to my problem. Everything else is a tower of garbage that I have to chop through with a machete in order to get to the task that I actually want to solve.

And, as I understand it, somehow the web and Javascript universe is worse.

So, no, I don't want to learn.

Wow, that's a truly horrible tech stack. Flutter, not even once.

Most of that isn't flutter. It's the Android tech stack. iOS isn't any better with Xcode, Swift, Cocoapods, Ruby, etc.

Flutter and Dart are actually some of the more interesting things that I'm not so irritated learning.

This is a classic issue of leaky abstractions, so it is definitely "caused" by Flutter/Dart. What led to this might not be their "fault", but as it stands this is something that only Flutter/Dart can solve.

It is not strictly necessary to use Gradle/Groovy to build an Android app, so to use it was Flutter/Dart's choice. Just as it isn't necessary to use Xcode, Cocoapods or Ruby (of course, you still need either Objective-C or Swift, but only one) to make an iOS one. Same for Oboe: it could be prebuilt rather than leaving it all to you (although depending on how you're using it, it's debatable if it's Flutter/Dart's concern).

The bottom part of the stack doesn't have control over the top part. Gradle can't really modify itself so that Flutter's abstraction is no longer leaky. Save for some ruling by Google/Apple/etc, the reason you need the whole stack is not because of some fundamental need, but rather because it was a choice made by the tools at the top of it.

> It is not strictly necessary to use Gradle/Groovy to build an Android app, so to use it was Flutter/Dart's choice. Just as it isn't necessary to use Xcode, Cocoapods or Ruby (of course, you still need either Objective-C or Swift, but only one) to make an iOS one.

This may all be technically and pedantically true, but I have never seen an app built without either of those stacks. And I've been doing this an awful long time.

Yeah, because of a technical choice made by higher level tools.

And I've worked on a few games that didn't need some of those. On iOS's side there's Swift Build Sysyem and Swift Package Manager that almost remove the need for Xcode. And there's also things like Cordova where some of those things are used but fiddling with them isn't needed for 99% of the cases.

It's funny how this is similar in the frontend where people constantly complain about the tooling, but as soon as they hear that apps can be built without bundlers/transpilers (because modern browsers support A LOT of things), but go "yeahhhhhh right but in practice you need webpack because I never seen anything without it in my super vast experience of building the same thing over and over and over". Well...

Good example. "Another yak to shave" is a great analogy too. I think we are saying the same thing: we don't want to learn anything that has no direct bearing on our problems. Learning how to design an infinitely scalable metadata service for a stateful service is a delight. Learning how to use Terraform is an abomination.

While I understand the sentiment, I don't really get the particulars.

So, instead of learning Puppet or Terraform, you want to implement one from scratch?

I have that itch too, I also try to implement the basics of something like git or Ansible in my own toy system when learning it. But that's just to get some hang of why the tool looks like it does. I'm still there to use the tool.

That goes double if you're working with others. I totally get the bit about wanting to learn fundamentals, but not the bit how it turns you off some higher level tool.

Not really. Use whatever technology that you know best, but hide unnecessary complexity through the right tools. I'm not sure about the OP, but I had extremely good experience when I was in Netflix. A single engineer, Joe Sondow, created the app Asgard. Using Asgard, I didn't need anyone to teach me how to configure clusters or networking topologies. The app got affordance, consistency, and constraints right, to the point that at any point what I guessed was either right or the only way to complete my tasks. Michael from the cloud team created command-line tools for managing AMIs. They exposed just what one needs to achieve while hiding anything about how things were done. As a result, I can still remember how to use these tools, years after I left Netflix. Similarly for doing service discovery, fault injection, load balancing, autoscaling, predictive autoscaling, logging events, publishing metrics, and the list can go on. Everything in Netflix, at least when I was there, followed the unspoken principle of making everything a non-event: zero unnecessary mental load, maximum flexibility, maximum freedom to engineers, and full transparency. Things just happened. Tools were just in place. The tools could be primitive and could lack of features, but the they did not get in my way whatsoever.

> [The AMI management tools] exposed just what one needs to achieve while hiding anything about how things were done

No, they exposed just what _someone working at Netflix who produces AMIs for Netflix's infrastructure and is required to conform to assorted Netflix expectations lest they be told to go pound sand_ needs. Accepting that constraint makes the problem much easier. When you try to make a general-purpose tool, you rapidly run up against:

- Some other user needs to do something that you don't, that the existing configuration surface cannot possibly account for. You now have either a tool that exposes two (and soon, three or four or five ad infinitum) means of doing thing (likely without any indication why you'd use one or the other) or a tool that exposes <original means of doing thing> and <fill in your own thing from scratch>.

- Someone has other parts of their infrastructure whose design is, for lack of a better description, "fucking stupid". They don't have the power or will to change that, but they're happy to ask you to include a workaround for it in your product. They also have a number of friends whose surrounding infrastructure is similarly fucking stupid, and some of those are important contracts where sales will force your hand to build the workaround instead of asking the customer not do fucking stupid things.

Yes, a single well-managed organization can delegate various pieces of complexity throughout the org and avoid having other parts worry about them. General-purpose tools do not have that complexity. The reason you have to learn new concepts and tools to learn Terraform effectively is because you're taking all the complexity of dealing with a cloud services provider and then adding an additional layer of complexity on top to augment the things you can do with the cloud provider. The value proposition is that this still better than what you'd do by hand and, crucially, something that other people who know Terraform can understand. Realistically, you can hire another engineer who's familiar with Terraform. You can't clone Matt.

The reasoning above perhaps isn't so much related to your use of Sondow's tools, but how Sondow and his colleagues develops and maintains those tools.

I wrote my own Ansible+terraform alternative and frankly, for the limited use (demo of GCE launch, we could start over 1000 raw vms and be doing large scale compute in minutes during the live demo (unfortunately urs wasn't confident so we pretaped that part).

Ansible is not bad but tf is Terrible. Good idea, terrible execution and evolution

> So, instead of learning Puppet or Terraform, you want to implement one from scratch?

I definitely don't want to implement from scratch.

I share his sentiments. I keep hearing about Puppet Labs (i think is the right one), but I've been to the site a bunch of times and I end up leaving because I have no idea where to start. So I really donno how I would benefit over just using a few bash scripts or powershell scripts to manage my Linux/Windows servers inn AWS.

Many different things are like this. The barrier to entry is high, once you get started it becomes easier and you tend to agree that the tool is much better than other alternatives.

However I today learned that Pinia is the state management library that replaces Vuex in Vue. (effectively V5 of Vuex) and I opened up the documentation, and within a few minutes of reading I had it up in running in my little side project. The documentation explained why its now Pinia, and gave a concrete working example of a simple counter and how its used.

Vue, Rust, Postgres - these all have my favourite documentation.

If a few bash scripts is enough for you to manage your servers, you probably don't need puppet (or ansible, or chef).

But, yes, I agree that the puppet documentation is (or at least was, I have not looked at it for several years) not entirely brilliant. It is an OK reference manual, but like so much documentation, it is more difficult than necessary for learning the thing.

I don't understand how you were able to make the jump to "I don't like tools that lie about complexity" to "I want to build tools from scratch", but I share GP's complaints. The problem is clearly with tools that promise simplicity for users but are actually only simple for the creators of the tools themselves. For end users there's still a lot of complexity.

And it's not that complexity is a problem per se. It's just that it exists on multiple levels. And some of those tools aren't abstracting much or anything at those levels. They're often just providing yet another thin API for something that's still complex for their users, so they haven't really made the hard thing simple, maybe they simplified the 10% of it that don't matter at the user's scale. If anything they introduced even more complexity. Aka, leaky abstractions. Of course, YMMV.

Also: if you have to tell me it's simple, rather than showing me examples that make it apparent, I assume it's not.

I think it’s fair for a project as a whole to describe itself as “simple” as a statement of its goals (vs. e.g. “flexible”, “high-performance”, “easy-to-use”, and so on).

For example, Suckless Software describes many of their Linux applications as simple, and it’s a fitting description that also encodes the spartan nature of the projects compared to their more commonly used counterparts.

But outside of a README or GitHub project description, I completely agree. Simplicity is the absence of complexity, and will become in retrospect when users choose what you’ve made because you made it simple enough to do so.

I don't think it's fair. Simple is subjective. Goals should be objective. I don't want to know and understand the entire context in which a project was conceived.

Simple is subjective, which means it shouldn’t be used in contexts where accuracy and objectivity are paramount (like technical documentation).

But if I’m searching for e.g. a “simple monitor hardware brightness control for Mac” without extra nice-to-have features or GUIs, a project that describes itself as “simple” gives me a useful clue that the developers might have priorities that match my needs.

For some reason this comment played in my head in Gilfoyle's voice.

None of the technologies you've named could be considered "6-month-or-less half-life stuff."

Puppet in particular is ancient by tech standards and is still getting used to date.

They're being used, but less for new projects

True. The shelf-life refers to how long one cares to remember the technology. The unfortunate fact is that these techs are so specific that I simply forget them weeks after I don't have to use them any more. The entire Uber engineering team had to endure the horror of writing hundreds of lines of oh-my-god-it's-so-cool-dsl Puppet for simple deployment tasks and waiting for on average 15 minutes before a change took place. Guess how many people missed Puppet when it was ripped off Uber's infra? Probably only the dude who thought Puppet and Graphite were the best systems in the world. And guess how learning the intricacies of Puppet helped anyone's career or ability to build better systems down the road? The answer is zero and zero.

I can relate. The thing is, that these "Heureka" moments stem usually from long times of frustration working within a certain domain or with a certain concept.

After working with certain stuff for long periods I can find usually a way to explain it in a very easy way. However, this does not mean, that concepts are easy to grasp without putting in more time and learning all about what my abstraction kept out.

It is still a hermeneutic circle.

I think this is just a subset of the larger guide, don't brag about subjectives.

Don't say your product is the best, the greatest, the simplest, the most powerful. That's marketing BS, noise.

It's ok to say things that can be verified, like it's the cheapest, the fastest, the only one with yellow spots.

Or, if you really do want something qualitative: “my favorite”.

Why wouldn't you say it if it helps to sell the product ? It's marketing, not science.

This is such a pet peeve of mine, especially when peeking at other programming domains I don't typically work in. Seeing readme's say "Simply..." or just throw around domain terminology with 0 context immediately puts me off using the library.

Everything seems simple once you're an expert at it. Experts are often the worst at teaching it for that reason.

Reply on news.ycombinator.com