Ask HN: Do you use your favorite programming language at work? - <AUTHOR>

Hello HN,<p>I have met many people who are very passionate about certain programming language, however for many reasons that language is not the main one used on their job. Has this happened to you? If so, do you still use it for some side projects where it's fit?
Or in the other scenario do you enjoy using it at work? <comment><USER2> No...and to be honest, I'm pretty sure the majority of us aren't working with our tool/language of choice. The nice thing about that though is you get to bite the bullet and step outside of your comfort zone. I think that's one of the things that separates good devs from bad ones...the ability to pick up new (or in most cases old..if you're going by release date) toolsets and hit the ground running

<comment><AUTHOR> I agree with you about this making you step out of the comfort zone. Also I think some people might prefer to work solving certain kind of problem or in certain area independently of the languages and tools involved.

</comment></comment><comment><USER3> I get to use Ruby, Coffeescript and Sublime Text 2 for work. I'm covered.</comment>


Uncle Bob and Silver Bullets - <AUTHOR> https://www.hillelwayne.com/post/uncle-bob/ <comment><USER2> Here is the post this post is in response to:

[http://blog.cleancoder.com/uncle- bob/2017/10/04/CodeIsNotThe...](http://blog.cleancoder.com/uncle- bob/2017/10/04/CodeIsNotTheAnswer.html)

I don't interpret the original piece as saying any of these tools and techniques are not useful.

I interpret it as saying average developer mindset needs to shape up.

I tend to agree. I work with guys who believe in formal reasoning tools (we collaborated with Amazon's ARG for example[1]), and use all these tools. These guys are almost compelled to write these tools and evangelize using the tools in an effort to help, because the developers around them don't carefully reason about their code and it makes the guys who care crazy.

So you have two camps. People who believe correctness is important, and people who think continuous deployment is an answer to bugs. The first group is trying to help the second group through tools that can become part of the SDLC.

I read "Uncle Bob" as suggesting that's not enough, it's not the root cause — the second group needs to care.

I see nothing in his post that suggests the tools shouldn't be used. ("I think that good software tools make it easier to write good software.") But if the crowds in his talks aren't using unit tests, are they really going to be using TLA+?

First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+.

I take that as his point, and it seems painfully valid.

1\. [https://www.slideshare.net/mobile/AmazonWebServices/aws- rein...](https://www.slideshare.net/mobile/AmazonWebServices/aws- reinvent-2016-automated-formal-reasoning-about-aws-systems-sec401)

<comment><USER3> > First, do no harm, then use like Light Table, Model Driven Engineering, and > TLA+.

Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing them.

For example, in [http://blog.cleancoder.com/uncle- bob/2017/01/11/TheDarkPath....](http://blog.cleancoder.com/uncle- bob/2017/01/11/TheDarkPath.html) he asks: "It is very risky to have nulls rampaging around the system out of control. The question is: Whose job is it to manage the nulls. The language? Or the programmer?" and goes on to answer: "Defects are the fault of programmers. It is programmers who create defects – not languages." Then he goes ranting about programmers who don't test their code, and if only they tested, such type systems would not be needed.

Again: He dismisses the one thing that _actually_ forces programmers to be disciplined and instead just _wishes_ (against all evidence) that they were disciplined. To me, he seems to be saying "First, do no harm, then use tests, then nothing."

<comment><USER4> No tool will ever successfully enforce discipline. If anything, it makes people more lax.

"I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know."

"I don't have to pay attention to the road, Tesla's autopilot takes care of it for me."

All the tools do is enforce a loop of compile -> make compiler happy -> compile.

<comment><USER5> _No tool will ever successfully enforce discipline. If anything, it makes people more lax._

But the end goal is not disciplined programmers! It is better, safer and more timely software.

Your argument applies just as well to safety equipment in cars and on heavy equipment, and you may be right that the reduced risk of being killed or maimed makes people more lax. But you can't argue with the results: Far fewer people do in fact get killed or maimed!

<comment><USER6> Fewer errors get deployed to production code because tools help us catch them more often? Yes.

Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes.

Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough?

I'll go with the latter. And if he seems dismissive about the former, is because he's trying to teach about discipline, which is far more difficult to teach, than to use a tool or follow some process.

<comment><USER5> You're creating a false dilemma. It's entirely possible to be a disciplined programmer _and_ use good tools.

And, yes, a teacher should care more about the skills than the tools, but Uncle Bob is actively against the tools, claiming that they impede learning the skills. Which is no more true than claiming that automatic transmissions or anti-spin in modern race cars impedes learning how to race.

<comment><USER6> I don't think he's actively against those tools. I think he's actively against claims that those tools actually solve the problems developers deal with, instead of uncovering the true behavior that lies beneath those problems.

<comment><USER5> No, he really is against the tools. He is on the record as being opposed to static typing, optionals etc.

And by the way, noone is making the argument that tools solve _all_ the problems developers deal with. But to say that actually, they solve none of them, is foolish. Optionals, to take one example of something Uncle Bob is against, prevents a large proportion of what is probably the most common runtime error, namely dereferencing a null pointer. And yes, Uncle Bob is right that it comes at the small expense, which is having to think more carefully up front about your data and your abstractions, and there is no doubt he is right that some programmers will feel constrained and will find and use whatever mechanisms exist to bypass the safety that this feature offers. But in much the same way, there are also some people who feel constrained by seat belts, hard hats, helmets, dust masks etc. and choose not to wear them, yet you don't find many people who would argue that this makes them pointless and generally a bad idea.

<comment><USER6> No, he is not against the tools.

"I have nothing against tools like this. I've even contributed money to the Light Table project. I think that good software tools make it easier to write good software. However, tools are not the answer to the "Apocalypse"."

[http://blog.cleancoder.com/uncle- bob/2017/10/04/CodeIsNotThe...](http://blog.cleancoder.com/uncle- bob/2017/10/04/CodeIsNotTheAnswer.html)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feelings people allude to are warranted. In general, people are made to feel guilty for not being able to use the shitty tools and techniques we are given.

Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors related to ORMs / Hibernate, because of an actual mismatch between relational data and object graphs, but then developers are made to feel guilty because they " _aren 't using it right_", made to think that only if they switch this setting on, use this and that annotation, read a book or two, everything will be alright going forward.

Most such projects fail from a technical perspective of course, because the developers having invested so much time in those shitty techniques, exploration of alternatives becomes unfathomable to them, because all of that effort which can span years ends up being unjustified. And I suspect that Uncle Bob is guilty as well.

Lets take TDD as another example. I remember a time when TDD was religious dogma, which was unbelievable, because I couldn't see actual TDD in projects of companies advertising TDD in job descriptions. Much like Agile, Scrum and all that crap, it usually doesn't work because, as the masters will quickly tell you, you're " _not doing it right_ ". I've seen a single project where TDD was implemented by the book, but the developers where wasting so much time on testing stuff, including endless discussions, that they were forgetting TDD wasn't the actual artifact they had to deliver.

Now Uncle Bob tells me that we don't have the discipline required. That's not surprising. I've been hearing this argument in some form or another for years.

The surprise is the attention that we are paying to what Uncle Bob has to say.

<comment><USER8> Completely agree with this. The post where Martin derides modern, type-safe languages (Kotlin and Swift) [0] was just unbelievable to me.

 _" Ask yourself why we are trying to plug defects with language features. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often.

Now, ask yourself why these defects happen too often. If your answer is that our languages don't prevent them, then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages."_

Arrgh! Until we get out of this ridiculous, macho, victim-blaming mindset, software development will be stuck in the relative dark ages. More, better, safer languages, please!

[0] [http://blog.cleancoder.com/uncle- bob/2017/01/11/TheDarkPath....](http://blog.cleancoder.com/uncle- bob/2017/01/11/TheDarkPath.html)

<comment><USER9> Somebody should show Uncle Bob this: [https://youtu.be/fPF4fBGNK0U](https://youtu.be/fPF4fBGNK0U)

My point being: yes, if we'd be perfect drivers at all times and in all weather conditions there would be no more accidents. Luckily for us auto designers haven't adopted this perspective :)

<comment><USER10> The top comment on that video, in light of the points being made in this thread, is quite ironic:

 _" And because of this 'improved safety' we have millions of drivers out there who drive even faster and take even more risks, because they think the new cars are so much safer. "_

(of course this comment is silly, the number of motor vehicle deaths per capita is about a third of what it was 50 years ago: [https://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_i...](https://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_in_U.S._by_year#/media/File:U.S._traffic_deaths_as_fraction_of_total_population_1900-2010.png))

</comment></comment></comment></comment><comment><USER11> I'm usually pretty skeptical of Uncle Bob's stuff, but in this case I think that both Hillel and Bob are a little right. Tools _do_ make a difference, as Hillel says, and can be used to mitigate risk. The key word there is _mitigate_ , though. Bob is right in that the root cause of that risk is a lack of discipline. Such risk will persist, mitigated by tools or not, so long as that lack of discipline persists.

I think that "discipline" is a bit of trigger word for some folks, though. It can be seen to imply a personal failing, but as Bob's post explains "undisciplined" programming is usually a combination of personal and systemic problems. The programmers who created the hypothetical bad code shouldn't have created it, but they also shouldn't have been asked to, or placed under requirements that made bad code, over a long enough time, inevitable. You can have undisciplined cultures in the same way as you can have undisciplined programmers, PIs, requirements, or problem domains.

What's more, all of those are problems that it's important to be aware of. If anything, Hillel's article pushes a bit far (understandably) in the other direction, hinting that a failure of discipline is so inevitable as to be a waste of time to fight against.

It's important to do both: mitigate the impact of failures caused by lack of discipline, and understand and try to address the causes of that lack. Easier said than done, of course.

<comment><USER5> _I think that "discipline" is a bit of trigger word for some folks, though. It can be seen to imply a personal failing, but as Bob's post explains "undisciplined" programming is usually a combination of personal and systemic problems_

I think you're on to something here, but you're not all the way there. I think "lack of discipline" is such an unsatisfactory explanation for anything, and almost never the _root cause_ of any problems, as you claim in your first paragraph. The reason it unsatisfactory is that it leaves us with no other remedy than to try harder. But if the root cause is systemic, then merely trying harder is bound to fail. If we are to gain any insights, we have to look closely at the systemic issues that manifest themselves as a lack of discipline. Saying that the cause of undisciplined individuals is an undisciplined culture doesn't really get us anywhere. We have to understand _why_ a culture can get that way. What it often comes down to in my experience, are incentive structures inside or outside of that company that have negative side effects or are downright dysfunctional. Sometimes you can fix them, other times you just have to accept them and live with them.

</comment></comment><comment><USER12> Uncle Bob (2017)

 _I stood before a sea of programmers a few days ago. I asked them the question I always ask: "How many of you write unit tests on a regular basis?" Not one in twenty raised their hands._

Rich Hickey (2011)

 _It passed all the tests. Okay. So now what do you do? Right? I think we 're in this world I'd like to call guardrail programming. Right? It's really sad. We're like: I can make change because I have tests. Who does that? Who drives their car around banging against the guardrail saying, "Whoa! I'm glad I've got these guardrails because I'd never make it to the show on time."_

[https://github.com/matthiasn/talk- transcripts/blob/master/Hi...](https://github.com/matthiasn/talk- transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md) incremental search "passed all" for the rest

<comment><USER13> Disclosure: I _didn 't_ like the talk.

In Uncle Bob's view, which I assume has some popularity, unit-tests are a form of software specification. It's informal as the specification can only test specific examples of behavior based on a determined state and the people responsible for its maintenance are the programmers. And if you're not disciplined enough with how you write these tests you end up in a situation where you're writing the rules for your own success and the specification itself contains errors.

I look at specifications as blueprints. If you're planning a sky-scraper or mass transit system you use blueprints. If you're building a shed in your backyard you might just use a quick sketch on a napkin. I think the majority of commercial software is somewhere between napkin and blueprint; building houses to lean on a well-trod analogy.

You need something more specific and robust than a sketch on a napkin but not quite as formal as a blueprint for a rail switching system.

Regardless unit tests are not a very good specification format. They're only going to show you examples where your software meets your requirements. However we all know that software is complex, hard, and systems are more than the sum of their unit test suites: there are operators involved, conditions and constraints on its operation, failure modes. You need a tool to help you design the system and check your work for you because _these systems are getting too complex for you to reason about without solid abstractions_.

I think Rich Hickey completely missed all of this when he said that in his talk. If we were to modify the analogy to fit the view of testing as described the guardrails would have holes in them. All over the place. You'd only be safe in the cases where the car "bumps" into the correct spots you thought to put a test.

However I do agree that unit tests alone cannot be relied upon as the only way to write "correct" software where "correctness" is determined by it's adherance to its specification and that the implementation of it follows state of the art practices. One has to do more than just use unit tests to achieve that.

<comment><USER7> Building houses is not the right analogy to building software, because the used techniques are known and most new buildings are going to be exactly like the millions of other buildings that came before it, even when speaking of sky-scrapers. There's very little innovation in it.

Building a new building is usually akin to _copying /downloading software_, only more expensive. Art is involved in designing buildings sometimes and there is some innovation for the engineers that want to break records, e.g. in building the world's tallest buildings or in building them faster, but I think those are a minority.

I don't think Rich Hickey missed the point at all. If I ever saw an actual _software architect_ , then Rich Hickey is one.

I think you missed his point of view, because Rich Hickey is also the guy that helped create Clojure's Spec and is a proponent of property-based testing, which Clojure's Spec now enables.

In fact Rich Hickey, in "Simple Made Easy" and other presentations, likes to talk about about the need for upfront design, for carrying about the delivered artifact, for thinking deeply about architecture, for simplification. He's in no way proposing a napkin-driven approach, quite the opposite ;-)

</comment></comment></comment><comment><USER14> Well written! I've always cringed when I've read anything that Uncle Bob writes. It almost seems like his entire existence depends on the acceptance of unit testing, and the unjustified dismissal of tools, especially type systems, seems to me something a only a novice would do when evangelizing their favorite lang (we've all been there, right?...), until they get more experience with other methods and approaches.

<comment><USER15> I never understand why Martin gets the kind of attention he does. As far as I can tell, the only significant achievement he's done for the technical community is the Agile manifesto. Outside of that, he's a typical consultant in that he's got books, training courses, etc. However, I have yet to find a significant publicly known project he's been involved in where he's had to put his principle into practice.

<comment><USER16> There's definitely two types of very well known speakers.

People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success.

Then there are people who I have no idea what they have ever written at all. Robert Martin, Martin Fowler and so on. I don't know if I should listen to what these people say at all. Does it work? What software projects have they made a success that I can look at?

I suppose in the latter case it's usually closed-source enterprise code that they've consulted on? Well if I can't look at it I'm not sure I'm just prepared to take their word that it's successful.

Is this reasonable of me?

<comment><USER17> > People who have worked on some really notable project. Linus Torvalds, David > Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth > listening to because I can see that their code is a success.

I agree with your examples, Linus Torvalds in particular. However, I would not consider Mark Zuckerberg, Steve Jobs or Bill Gates worth listening to on a technical level just because their products are a success.

<comment><USER18> Bill Gates was actually a pretty decent programmer. His technical insights peter out somewhere in the 1980s or early 90s at most, but he's had some interesting things to say about those eras. (Interesting in the sense that it's someone speaking about the eras that was there in a big way, not necessarily because he's got surprising insights into software engineering or something.)

<comment><USER19> Do you have any links to his insights? They sound pretty interesting but I'm not sure what to search for to find them.

<comment><USER15> [https://www.joelonsoftware.com/2006/06/16/my-first-billg- rev...](https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/)

<comment><USER17>
      He didn't meddle in software if he trusted the people who
      were working on it, but you couldn't bullshit him for a
      minute because he was a programmer. A real, actual,
      programmer.

I stand corrected. Thank you for the read.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Discipline is a good thing, but it does not scale.

I work on a tool for mutation testing for C/C++[1] for a few years now. During this time I was thinking about tests, tools, people, etc. a lot. Here is the summary of my musings:

Quality of software depends on several factors such as hardware, operating system, programming language and tooling used to build the software in the first place, etc. For decades we try to improve each of those aspects. But, the most significant and most harmful factor is the human. Naturally, we cannot improve developers, but we can decrease the destructive influence of a human being by using better tooling.

[1] [https://github.com/mull-project/mull](https://github.com/mull- project/mull)

<comment><USER21> Or alternately: we _can_ improve developers, but doing so is hugely expensive and time-consuming, and while we can improve them we can never make them _perfect_. So making tools that can be used safely by imperfect developers is always going to be simpler and more cost-effective.

<comment><USER20> Exactly, this is what I mean by "do not scale." It takes many years, if not decades for one to become a decent developer. We simply cannot afford this.

<comment> dorian-graph We can't afford it with the current pipeline, but perhaps with a better pipeline, we can. Perhaps something more proper and akin to the older engineering disciplines? Or to doctors?

They're doing incredibly important jobs, and spent an appropriate amount of time learning and proving them selves.

Software is now completely critical in so many aspects of the world, and becoming more so. When people's lives are at risk, we can certainly afford 'many years'.

Yes, not everyone is working on perhaps safety-critical systems, but more and more people are. It's not just safety in the physical sense either, but emotional and mental well-being too. Facebook isn't saving potentially affecting lives as how a doctor would (more 'physical'), but social media definitely has emotional and mental effects.

<comment><USER20> I think this is a fallacy. I believe another pipeline does not necessarily produce better doctors. They also make mistakes; sometimes those mistakes cost people lives.

</comment></comment></comment></comment></comment><comment><USER22> Not directly on topic - but I was a hobbyist silversmith as a teenager. I learnt many of my skills from a stern old German bloke at the silversmithing club.

He liked to say "Gutes Werkzeug ist die halbe Arbeit" (or sometimes: "Gutes Werkzeug, bessere Arbeit"). A good tool is half the work, or: Good tools, better work.

This idea has informed my coding decisions too. Evaluating the worth of a tool is more complex in software than in silversmithing, though.

</comment><comment><USER23> I think the thing is that the we have _a different level problem_ in software, that can't be solved by either "methodologies" or "patterns" 0r "discipline" or languages...

We have a _learnability_ / _teachability_ / _knowledge transmission_ problems that always disguises itself as a technical problem... If you could simply "distill" and "transmit" the relevant design knowledge to the person requiring it under a ressonable amount of time most software quality problems would become trivial.

We supposedly do "knowledge work"... but we learn mostly from experience, like _cooks_ or _handcraft artisans_ or whatever, instead of how civil engineers or auto engineers do. (And I suspect the problems is not just immaturity of the field... it's more that "the space of possible solutions" in software architecture is _so insanely big_ that there's no way to learn/label/teach what the engineers need to know... we have the requirements of engineering, but the infinite solutions space of mathematics... and training successful mathematicians is something _we know we have no clue how to do_... only here we also expect the "untrainables" to have the professional conduct of engineers coupled with the depth of though of philosophers.)

</comment><comment><USER24> The problem is that the more tools you add, the more mistakes you make in the tools.

This is the same debate we had previously about formal methods. They don't eliminate errors, they just move them to the testing systems and where there are several the gaps between them. Communication becomes more difficult between the people involved and you rapidly start looking for the Chief Programmer Solomon who knows everything. then you get communication failures because not everybody is Einstein.

So it is always a trade off.

And it would help if we stopped calling automated testing as testing and described what it is - a domain specific type system checker.

If we realised we always build a system and a compiler for that system we might stop reinventing the wheel so much.

<comment><USER25> I don't get why automated testing is a "domain specific type system checker". Not saying it's not, I just don't get it. Maybe that's because my automated tests are pretty free-form and tend to be more about throwing mud at an algorithm and seeing if the results stick.

Your last line is bang on, though. We build a system, and a compiler (or processor) for that system. It doesn't matter if everything is "data driven" if your data is code and the thing it's driving is an interpreter.

<comment><USER26> > I don't get why automated testing is a "domain specific type system > checker".

That's because he was talking about formal verification. Testing like the name is normally used is a "adhock domain specific heuristic type system checker".

</comment></comment></comment><comment><USER27> I'm sure this comment will get buried because I'm so late to the thread but oh well.

"Later, the guilty programmer thanked the lead developer for protecting him. He said: "I knew I shouldn't have reused that code, but we were in a rush." She smiled at him and told him not to worry about it."

This quote describes the real issue. Uncle bob is equating software development as some kind of unified profession and making apples to apple comparisons for all software projects. But software development is not like being a civil engineer or being a doctor. Writing software is totally different from heart surgery or bridge building.

Software development is applied differently to all projects and all projects having varying needs about quality and cost. If you are building a bridge it there is a high standard of quality every time. If you take a shortcut you may kill people, or more likely never pass inspection.

In software sometimes you could kill someone but far more often the quality of the software may not matter. There are times when it makes sense to cut corners, there are times when it makes sense to do a quick hack, there are times your boss makes the decision to something the worst way possible and fix it later, and sometimes that's ok. There are other times when it's not ok.

Every person on earth has an ethical obligation to not bring physical harm to others and should avoid doing so even at the cost of employment. But no one has an ethical obligation to write "good" code just for the sake of it. There are times when the best thing for everyone is writing software badly.

Maybe software engineers should have some widely disseminated ethical principles, but they have to be realistic and take into account the entire spectrum of software development. We have different ethical standards depending on the type of project we are working on. If you are a developer working on software for Airline Autopilot you have different ethical obligations from a developer working on Angry Birds 10.

</comment><comment><USER28> I think the author completely misses the point of Uncle Bob's article for two reasons.

First, in "Tools are not the Answer", it is clearly stated that tools are valuable.

Second, Uncle Bob's article is not telling programmers to be better. It is telling programmers to be professional. It is not like telling drivers to drive better. It is like telling drivers to stop texting while driving.

<comment><USER29> :-)

</comment></comment><comment><USER30> Both "Uncle Bob" and the author are selling extremely complicated, cumbersome, expensive ways to develop software -- great for them as consultants if they can pull it off, not necessarily great for their customers. Giant near monopolies such as Microsoft or Google can afford these methods, may even benefit from this sort of super-bureaucratic "gold plating" of software and certainly do benefit from convincing small potential non-monopoly competitors to adopt these slow, expensive, bureaucratic methods that smaller firms cannot afford (they run out of money trying to create perfect software instead of software that works and gets the job done).

<comment><USER31> Perhaps if the methods are sound (even if expensive) then someone can step up and make tooling or refine them so the methods are more accessible to smaller firms. Uncle Bob's opinion's might be discouraging people from exploring them and finding ways to drive down the cost of adopting these better methods.

<comment><USER32> > Perhaps if the methods are sound (even if expensive) then someone can step > up and make tooling or refine them so the methods are more accessible to > smaller firms.

To his credit, Hillel is trying to evangelize (in general, not directly through the post linked) a particular tool (TLA+) whose creator (Leslie Lamport) wants to do exactly this. I don't know how big Hillel's employer is, but from what I understand it's nowhere near the biggest engineering firm in number of technical employees. Lamport's current objective with TLA+ is to get people to learn concepts for formal _description /specification_ of systems, and he happens to provide an effective tool for testing those system specs.

Check out his TLA+ tutorial at [https://learntla.com](https://learntla.com).

If you want an example of solving concurrency issues, jump to here: [https://learntla.com/concurrency/processes/](https://learntla.com/concurrency/processes/).

<comment><USER33> We have about ten engineers, so nowhere near the size where people consider formal methods "appropriate". Nonetheless it's still been incredibly useful for our work.

I'm a pretty huge evangelist of TLA+, but I don't think it's the silver bullet of software correctness. It just happens to be the tool I'm most familiar with and the one I thought could benefit most from a free guide. If people start widely using TLA+, I'll be ecstatic. If people ignore TLA+ but start widely using Alloy, I'll still be ecstatic. Software correctness is a really huge field and there's lots of really cool stuff in it!

Speaking of making methods more accessible, I'm working on a tutorial about Stateful Testing. Hypothesis ([https://hypothesis.works](https://hypothesis.works)) is an absolutely incredible property-based testing library for Python, and I think it could potentially make PBT a mainstream technique. One of the more niche features is that you can define a test state machine that runs by randomly selecting transitions rules and mutating your program state, then running assertions on the new state. It's really neat!

</comment></comment></comment></comment><comment><USER34> This is unfortunately a very defensive article. The author would do better if he chilled out a bit.

I get why he's defensive: Martin calls his baby out in his article. And, although I think that Martin himself comes across as defensive (he is alarmed that the journalists didn't interview 'real' experts like himself), I also don't think he is wrong. In fact, as a practitioner for over 20 years, I've witnessed first-hand the gradual degradation of software discipline. I've seen too many companies do exactly as Martin describes, and it causes many issues: from critical bugs to developer burnout.

It's important to look at the root causes. I surely don't have all of the answers, but I do note the rise of the 'startup culture' as a major issue. Even at big organizations, employees are now expected to run projects using extremely low resources. The companies encourage this behavior saying things like, 'think of your program as a startup'. Startup is the new executive buzz word.

Startups are obviously great, but they take on extreme amounts of risk. And, since people only see the survivors, they naturally make the (erroneous) logical conclusion that startups are silver bullets and have guaranteed return on investment. Therefore, every project should be a startup! And, with that, we see skeleton teams with huge responsibilities and expected return but a deficit in resources. Today, an engineering team of 4 people is expected to do the work of 16 people circa 1995. Team leaders accept this pain and manage it by sweeping issues under the rug. As a side note, it tends to cause people to be more unethical.

The examples that the author uses (Amazon, Microsoft) are not representative of typical software organizations today. Amazon and Microsoft have huge amounts of resources available. They have veterans and researchers able to take things like TLA and apply them to real projects. They have the ability to manage their risk. But, a typical team is strapped for time and they must rely on tools to save them at the expense of software discipline.

Anyway, my point is that investors want huge return on investment. This causes sales and marketing teams to over-promise and under-price. This causes delivery teams have to drive their projects with extreme risk. Extra people are too expensive, so just wing it. If you survive, maybe you'll get to build it right the second time. If you fail, well rinse and repeat at the next place.

<comment><USER35> I can't imagine many other industries as rife with false economies as Software Engineering. There are so incredibly many opportunities to appear to get things done quickly today, only to find that you've hamstrung your future self.

</comment></comment><comment><USER36> The article just focused on Uncle Bob's asking for "unit tests" in "Tools are not the answer". But I believe Bob just asked a rhetorical question over there. If someone is not writing unit tests at the very first place, he doesn't need to ask any other kind of tests furthermore, which are likely be less and less people raising hands.

</comment><comment><USER37> I stopped reading Uncle Bob's articles a few years back, after he started making money by telling programmers they need to be more disciplined to prevent bugs.

While he's not exactly wrong, he does dismiss any other solution than testing (such strong type systems). One reason could be that he doesn't make any money out of these solutions.

All his blogs and talks seem to send the message: "pay for my content and learn how to be a good programmer by writing tests". Again, not necessarily a bad thing, but there might be other ways than only hand-crafted tests.

</comment><comment><USER38> Humans are really really bad at static analysis. A 486 with 8Mb of RAM could outperform any human at this task.

The solution is more and better tools.

</comment><comment><USER39> I agree with the author of the article to an extent - there's lots of things about Uncle Bob's advice I don't care for. But...

I agree with Uncle Bob's take that discipline is lacking in software development today. It's not that people won't make mistakes if they are more disciplined - of course they will - but it's the kind of mistakes people are making that might change. I see code written every day that, when I give even a cursory glance to the PR, I can tell there are issues. The developer didn't even do the barest due diligence to make sure they didn't break things.

Formal verification and other software correctness tools can be great in the right circumstance. I think anyone doing life-critical software should be using something above and beyond the basics.

But, for most projects I see - formal verification isn't really a solution to quality issues. Having developers who give a damn and have a little paranoia and pessimism ("how is this thing going to fail on me?") would do 100 times more for the outcomes. In my mind the best code is the kind you didn't write, and the best infrastructure is the kind you didn't need to stand up, and the best distributed system is no distributed system.

</comment><comment><USER40> I've thought for a while the real solution to bad software is simple: hire intelligent developers who care

Only problem is, they are few and far between... (in my 10+ years in the industry, I've worked with only 3 people who I'd put into this camp)

<comment><USER41> Those intelligent developers who care need to make sure the less intelligent, more indifferent developers up their game. Tools and processes are put in place to mitigate risk from that second group, but it's the seniors that need to be able to transfer their mindset to the others. Which may not always work, mind you.

What should be avoided if possible is the hero developer; the risk there is that the hero dies or moves on and leaves behind unmaintainable work.

<comment><USER42> The risk? Hahaha. It's the reality. The hero eventually moves on an you're left holding the bag

</comment></comment></comment><comment><USER43> I'm still going to read the hell out of all of Uncle Bob's books. Every programmer has his faults and Programming is more of an art than science at this time in history.

</comment><comment><USER44> Uncle Bob's true value to me was to teach me how bad of shape the software world really is in. Look at any engineering discipline. There are standards, there's a rigorous design process, there's checks from more experienced engineers, there are best practices, etc. Software is like the wild west, and if people don't realize that and try to create some sort of standard than eventually someone with no knowledge of the field will. He's trying to encourage people to understand the problem and think towards creating rules so everyone can perform and collaborate better. Eventually software will become like other more established fields but it's up to our generations to take us there.

<comment><USER45> > if people don't realize that and try to create some sort of standard than > eventually someone with no knowledge of the field will.

I don't think so... No one's hunting down and calling to account the engineers responsible for the Equifax breach, and nor should they. The problem is blatantly a leadership and resource-allocation issue, and is being treated as such.

<comment><USER44> Bad software has done worse things than release private info. Just a few worse things: failed space missions and cost NASA credibility, killed hospital patients, bankrupt Knight Capital, almost caused World War III due to a false- positive nuclear-launch warning, caused wide-spread blackouts, killed people (lookup Patriot Missile).

We as developers are just waiting for something so terrible to happen that someone is forced to take notice.

</comment></comment></comment><comment><USER46> nah.

I think you could quite easily quantify the effect various tools have on a code base; adding unit tests, using a repl, static vs. dynamic etc. on the various aspects of your code:

\- How quick/easy is it to add new features?

\- How often do you add new bugs?

\- How long does it take to fix bugs?

...but I think you could _also_ look at the impact individual bad actors (the 'dont care' programmers) have on the same code base.

Now, because the 'dont care' programmers hack out rubbish at the speed of light, it may superficially appear that the net impact on the code base is balanced; more features, more bugs... but that rubbish slowly spreads out into the code base, and incrementally trigger a cascading bug creation rate for _all the programmers_.

Now, if you want to suggest that tools can add enough value to overcome the negatives from having rubbish programmers, I'm all ears, because I've never seen a tool that can do that. The bad programmers just abuse the tools or ignore them.

So... in that context, I think its fair to say, more tools really achieves nothing much, when bad programmers and bad programming practice results in such catastrophically bad outcomes for software.

Maybe, if you can make your tools nice enough and add enough processes you can kind of force bad programmers up a notch. I appreciate that; but the question _really is_ , why are there so many programmers who are so rubbish? Why do they never seem to get better? Why don't they care?

Do you really think you engineer a solution to that? ...because I think it's a social problem, not a technical one.

Maybe some tools can help, and maybe not everything Uncle Bob says is gospel... sure; but I think this is just stupid:

> Uncle Bob gives terrible advice. Following it will make your code worse.

I think history has objectively shown this is false; but of course, you're welcome to have your own opinion without any substantive basis other than that opinion itself if you like.

<comment><USER47> > Now, if you want to suggest that tools can add enough value to overcome the > negatives from having rubbish programmers, I'm all ears, because I've never > seen a tool that can do that. The bad programmers just abuse the tools or > ignore them.

So much this.

This perfectly matches my experience (and desperation). Bad programmers will do their best to work around tool-imposed limitations that they don't understand. And these workarounds will generally increase code complexity!

\- Force a minimum coverage ratio: they will create useless tests that don't check anything (without assertions).

\- Force a maximum on function sizes: they will split their methods halfway and pass the whole local state through parameters.

\- Force a "no-global variable" policy: they will create singleton classes.

\- Force a "no public member variable" policy: they will create set/get methods for their private members.

I'm not advocating for any of the above restrictions, they do more harm than good. Please, give me something I can put into my CI server that checks for bad coding practises, something that checks that the code stays SIMPLE.

Fact: you can inject a new disabled feature into a C codebase with zero risk of introducing any bug ... by wrapping your 50 modifications of the codebase into #if/#endif clauses. Guess what? This will make the code a lot more complex, will slow down every developer, and will increase the likelihood that they create bugs in other features.

Finding bugs is only the tip of the iceberg. What I want is to decrease the probability of their apparition, by keeping the code simple. Bugs and code complexity are correlated. Only targetting bugs will break this correlation, and we will be left with correct _rigid_ code (very hard to modify). Even if my compiler perfectly prevents me from breaking anything, I still want to be able to add a feature in a reasonnable time.

Let me summon Rich Hickey here: Simplicity Matters, and "nobody drives on the highway by bumping into the guard rails".

</comment></comment><comment><USER48> I think Uncle Bob is a great read just because he'll challenge some of your opinions and at least forces you to reason against his arguments. You won't have that if you only visit [https://swiftisfreakingawesomeblog.com](https://swiftisfreakingawesomeblog.com) or [http://www.igetpaidtolikethislanguage.org](http://www.igetpaidtolikethislanguage.org) where everybody repeats your opinion.

There's not a lot in Clean Code that I wouldn't recommend to most programmers.

<comment><USER49> I strongly recommend against reading Clean Code, because it only applies to Java-like languages, and it doesn't really make good advice anyway. It doesn't even properly apply to C++, and certainly doesn't apply to languages with different models (like Ruby or Python).

Uncle Bob has made a very successful business out of saying things that sound profound, become popular, but are at best the technical equivalent of fortune cookies, and at worst are profoundly bad advice.

Seriously, in TypeWars[1], he says "My own prediction is that TDD is the deciding factor. You don't need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What's more, the benefits of that achievement are enormous."

This is so profoundly wrong on so many levels that it isn't funny. How do you measure coverage? If you're doing it by lines hit (which is how most dynamic language coverage tools do it), then you're not getting any sense of how good your boundary conditions or branch coverage is. If you have a better way of measuring coverage (typically branch coverage), then maybe _aiming_ toward 100% is good, but hitting 100% coverage is a complete waste of time. (I aim for ~85% coverage, depending on the code base and how much is boilerplate code.)

In Ruby, do you really need a unit test for:

        attr_accessor :foo

If you don't at least _access_ `foo`, SimpleCov will say that line isn't covered. You know what? It doesn't _need_ coverage, because when you write a unit test for that you're writing a unit test for the language.

Unless you're actively adding "attack tests" to make sure you have all of your boundary conditions covered, and at least know you can abort or recover from an error condition properly, your 100% coverage means absolutely nothing. Property Checks are better for this. Fuzzing and mutation tests matter to help find this. Even static typing (of which I'm _not_ actually a fan, because 15 years with C++ makes it clear that static typing is not that useful in weakly typed languages) can help find certain types of boundary conditions (look to Ada, where if you declare a type as a range 1..100, _only_ values within that range, or variables that can never exceed that range, can be used with that range).

And people take Uncle Bob seriously, even when he posts things that are just asinine attacks on people who have taken him to task when he is wrong (which, IMO, is far more often than he's right).

[1] [http://blog.cleancoder.com/uncle- bob/2016/05/01/TypeWars.htm...](http://blog.cleancoder.com/uncle- bob/2016/05/01/TypeWars.html)

<comment><USER50> > it only applies to Java-like languages, and it doesn't really make good > advice anyway. It doesn't even properly apply to C++, and certainly doesn't > apply to languages with different models (like Ruby or Python).

I disagree strongly. Sure, there are a very few parts that are more relevant to Java. However, the vast majority of the book is easily applied to almost any language. There aren't many languages that don't have variable names, function/method names, modules, etc. Some of the OOP principles wouldn't easily apply to C, or other languages like it, but a lot of the other advice applies easily.

</comment></comment></comment><comment><USER51> Defects in code do indeed come from sloppiness. Of course, real people are sloppy sometimes. So real systems need resilience in depth to help resist system effects from localized sloppiness.

The same set of arguments applies to security. The last few years of history teach us that nobody, not even state actors with deep pockets, can keep secrets forever. Don't we need to change our thinking about that, and make it so security breaches aren't uniformly disastrous? It's all about resilient SYSTEMS dealing with localized sloppiness.

</comment><comment><USER52> "Don't test the UI" is not equivalent to "No end-to-end testing." The XP people, for example, prefer to make UI a thin shell over a programmable interface that can be easily tested. Then, visually confirming the UI operates the interface is enough.

I admit I don't read much Bob Martin, but does he say you shouldn't use automated functional testing, e.g., Fit or Cucumber?

<comment><USER53> As far as I know, he actually wrote FitNesse and recommends Cucumber.

</comment></comment><comment><USER54> After reading the post by Hillel Wayne I decided to read Uncle Bob's article that is mentioned in the post ([http://blog.cleancoder.com/uncle- bob/2017/10/04/CodeIsNotThe...](http://blog.cleancoder.com/uncle- bob/2017/10/04/CodeIsNotTheAnswer.html)). After reading both posts, and after reading most of the comments on this thread, I have to admit that my inclination is in favor of Uncle Bob. I agree with most of the points Uncle Bob made in his blog post.

Tools are not the answer. TDD is not the answer. Agile is not the answer. More programming languages are not the answer. There is no silver bullet. For me the answer is to do the best I can, with the tools I have.

Never stop learning, always strive to improve my skills. And yes, it takes discipline.

<comment><USER55> I disagree. Neither of them is saying anything is "the answer". They are merely putting emphasis on different things.

From that perspective, I would say that Uncle Bob is more wrong. It doesn't make sense to emphasise discipline before best practices. Discipline is about following through on things and avoiding short cuts. That means in order to have discipline, you first have to have a procedure you are meant to follow in the first place.

Additionally, Uncle Bob seems to look at things from the perspective: "If you're undisciplined, better tools can't make up for that." Sure.

But, IMO, Hillel's perspective is a lot more useful: "If you are disciplined, better tools will help you do better work."

<comment><USER54> I agree that neither of them is saying anything is "the answer". I read my comment and don't believe I implied it either. What I'm stating is my opinion: For me the answer is to do the best I can, with the tools I have.

Never stop learning, always strive to improve my skills. And yes, it takes discipline.

</comment></comment></comment><comment><USER35> "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." \- Unknown

</comment><comment><USER56> If all we needed to write robust software was discipline, we wouldn't need high level programming languages. All we'd need is the documentation of the instruction set that we want to target.

Why are we still taking this geezer seriously?

</comment><comment><USER57> I think that automated testing is superior to any other tool/technique that we can use to avoid mistakes in programming. Can anyone argue with this? What is the alternative?

<comment><USER7> Static typing combined with functional programming is superior to automated testing, although the three are actually complementary, because automatic, property-based testing works better if you have type info (such that the library knows what values to generate) and referential transparency, because side effects can be awkward to specify as laws.

So it is not a coincidence that Haskell developers have innovated testing tools and are now sold on QuickCheck, those two working well together ;-)

Being the Scala developer that I am, I love ScalaCheck, but I've also used jsverify for JavaScript ... not as good as ScalaCheck or QuickCheck, due to not having static typing and type classes btw, but did the job.

<comment><USER57> Static typing or functional programming can protect you only from some types of problems. With automated tests you have the flexibility to define the problem you are verifying your code against.

<comment><USER58> By the same token, tests can only verify certain properties of a function. How could you test that a function is free from side-effects? How could you test it never returns null?

</comment></comment></comment></comment><comment><USER47> Let's dismiss ideas, not people.

</comment><comment><USER13> I think Uncle Bob is way off the mark here.

In _Clean Code_ he hammered in the idea that unit tests form an automated specification of some software system under development. This was a decent idea at the time. So why on earth would he tell people not to use type-safe languages or tools for defining better, formal specifications?

Probably because he has something to sell?

We need better tools, processes, and "disciplined" methods to writing software if we're going to tackle complexity and produce systems that can be considered robust, reliable, and _safe_. Unit tests alone are never going to cut it. There's a reason Microsoft Research has been heavily investing in formal methods: imagine the only specifcation for CosmosDB existed as a unit test suite. It'd have data-losing critical errors in it for years to come.

I liken Bob's post on discipline to be much like the snake oil used to sell Christian religions: _you were born sick, but if you believe in me only I can make you whole_. What a crock. There are plenty of smart, capable people out there writing perfectly good software. The problem in the industry isn't that developers aren't writing unit tests the way Bob Martin prescribes: it's that a great deal of hand-waving is done to following the state of the art and establishing processes for developing robust, reliable, and safe code.

The entire aerospace, space, and safety-critical systems disciplines in software development have been making huge investments in tools and languages to make managing the complexity of these requirements on software systems to be manageable, correct, and reason about. TLA+ is only one such tool and I think Hillel is right to point it out: you need more than one tool. Your entire process has to be built around avoiding errors.

There's a reason why engineers designing roads stopped calling vehicle collisions "accidents." Once you start looking for the real root of the problem, the system itself, you start to optimize for different goals in order to reduce the negative outcomes in the design of the system. Vehicle collisions still happen because of human error but a great deal more happen because they were enabled by the system: the roads, the vehicles, the by-laws.

In a similar fashion errors in software systems are _enabled_ to happen by different choices we make: stakeholders, deadlines, requirements, time to market, etc. The ISO/IEC/IEEE 29148 guidelines on requirements engineering encourage you to consider these factors as part of your specifications. If the operation of your system will only cause nuisance or interference with the business' goals then the risk is quite low and you might put more priority on time to market. However if there's more risk to harm people like say, losing their personal information and putting them and the insurance industry at greater risk, then I'd say you need to put in the effort to avoid those risks into your processes: use more formal specifications, use statically typed languages with sound type systems, write property-based as well as declarative tests, etc, etc.

If you start treating software errors like we started treating auto-accidents then you'll start to see where you can reduce the negative outcomes. Stop calling software errors as bugs just like we stopped calling collisions, "accidents." See errors as risk and look for ways to reduce your risk. Know where some risk is acceptable.

Uncle Bob is only calling programmers "undiscplined" because he has a few more books to sell to help them get better.

<comment><USER29> Well, that's not the _only_ reason. ;-)

<comment><USER13> Hah!

I have read your books and used some of that material to train several teams over the years to practice test-driven development. So thank you for the inspiration and drive.

</comment></comment></comment><comment><USER59> Just some cat fight.

One guy likes doing things in way, other does not.

Ignore.

</comment><comment><USER60> From the original post that is being replied to-

"The author did not interview software experts like Kent Beck, or Ward Cunningham, or Martin Fowler."

I mean no slight, but are Beck and Fowler really the experts of the field?

This is akin to the relationship guru who has been through three divorces -- often just declaring yourself an expert fools enough people into thinking you are.

<comment><USER61> Fowler wrote some good books ten to twenty years ago. Today he writes as if he is not sure if he gets microservices or not, which might prove he is honest, but he is not giving the bold prescriptions which will make money.

Beck is up there with Tony Robbins so far as I am concerned. Cunningham is famous for running a Wiki which was down for two years.

</comment></comment><comment><USER62> <sigh>

More nihilism, this time in programming circles.

It's a turbulent age. I can't wait for it to pass.

</comment><comment><USER63> Can we stop talking about Uncle Bob? He's like the old, weird, drunk, racist uncle at a wedding. His ideas haven't really been relevant for about 10 years, and he is increasingly posting ranty, politicised, attention-seeking diatribes...</comment>


The Tragedy of Saudi Arabia's War - <AUTHOR> https://www.nytimes.com/interactive/2018/10/26/world/middleeast/saudi-arabia-war-yemen.html <comment><USER2> Between the financing of Wahhabism around the world (and the liberal reaction of western governments to this), the liberal purchases of weapons and oil exports, it seems like the world is in bed with the devil.

</comment><comment><USER3> I'm hoping that after the bad press over killing Khashoggi, the US tells the Saudis to back off on the Yemen war. They are really the only people in a position to do much.

<comment><USER4> And what are the saudits supposed to do with the 100 billions worth of weapons?

<comment><USER5> That's their problem. They shouldn't be making it anyone else's problem.

<comment><USER6> It's also problematic for the arms dealers.

</comment></comment></comment></comment><comment><USER7> I found the following reddit discussions to provide more detailed perspective of this war.

View from a Saudi Arabian, [https://www.reddit.com/r/saudiarabia/comments/8wnbzl/](https://www.reddit.com/r/saudiarabia/comments/8wnbzl/)

View of an independent security analyst, [https://www.reddit.com/r/WarCollege/comments/8qyip8/](https://www.reddit.com/r/WarCollege/comments/8qyip8/)

</comment><comment><USER8> In 30 years from now, the US, Canada and UK selling billions of dollars of military equipment, support and training to the saudi regime will be seen as morally equivalent to when the US dropped thousands of tonnes of munitions on Cambodia. Or the use of Agent Orange in Vietnam, My Lai massacre, etc.

Worthy of war crimes prosecution in The Hague.

How hard is it, really, to take a principled stand and say that the most technologically advanced products of the NATO military-industrial complex should only be sold to similarly democratic countries? The Netherlands or Italy wants to buy some current generation air superiority fighters, gps guided bombs or surface to air missiles, sure. Saudi Arabia? Nope. Pakistan? No way. The Erdogan government in Turkey? Negatory.

In the particular case of the saudis' war against the Houthis, the US doesn't give a fuck, because you know who supports the Houthis? Iran. Anyone who's spent time researching the history and reasons for the last 50 years for the poor relationship between the US and Iran will immediately understand why. Basically, it's "fuck Iran, they've got what was coming to them".

It's a proxy war where they're using US munitions to attack things the US can't politically stomach attacking directly. If the Saudis started open warfare against Hezbollah (again, Iranian supported), I'm sure the US and UK would be just as keen to look the other way.

<comment><USER9> Pakistan and Turkey are democratic countries. Just saying. But I get what you meant.

Anyway, I don't have a simple solution to this complex problem. Should US sell weapons to India? China?

<comment><USER10> India has proved itself to be a politically and militarily responsible country unlike its western neighbour, which floundered embarrassingly at even basic human rights.

</comment></comment></comment><comment><USER11> Why is this article, which was the top ranked link on my list when I commented, no longer even in the top 200? What was the rationale for the mods (or algorithm) to censor this?

<comment><USER3> HN guidelines:

What to Submit

On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups...

Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon.

The mods routinely put a penalty score on stuff that doesn't fit that.

</comment></comment><comment><USER12> I dont mean to be defeatist. What can I actually do (as a guy with no voice - literally due to visa issues) to help here beyond just sending aid (which I am not sure is even getting there). Sending aid still feels like "here's some money so I am no longer guilty"! Any ideas?

</comment><comment><USER13> I always wondered why Germans in the 2nd world war didn't do anything to stop Hitler from committing genocide against the jews and others. But now I understand. Perhaps the biggest genocide of this century is happening now in Yemen. Not only we aren't trying to stop it, but we are sponsoring it and profiting from it. History will not be kind to us.

<comment><USER2> They didn't because most of them didn't know the details/the scale of what was happening and the extermination on the camps was only "discovered" after the camps were broken up by the opposing armies (depending on the camp)

"Discovered" because there were some reports of it, by one or two people, but I'm not sure how seriously they were taken.

I guess people concluded/knew some of this was happening, but the breakup of the camps was important for validation of the story.

(Edited given the responses)

<comment><USER14> That's the usual apology of the 60s through 80s, but it's simply not true.

Cardinal von Galen openly preached from the pulpit about the destruction of "unworthy life" (the T4 program) in 1941.

Concentration camp inmates often weren't strictly confined to some walled-off camp, but had to go to work brigade actions all over the countryside, where they had limited contact to the populace, who quite often slipped them a bit of bread or so.

Even when no such work was happening around the populace, it was an open secret. You simply cannot keep a lid on it when tens of thousands of Germans saw something keeping watch over the inmates, delivering goods to the camps, requesting slave labor from the camps, actually building the ovens, conducting trains to the camps, or with soldiers returning from the eastern front.

<comment><USER2> There was some knowledge, but it seems it wasn't so widespread. Also the Sonderkommandos were "rotated" (hint: they weren't relocated or fired) with some frequency

[https://www.reddit.com/r/AskHistorians/comments/6b1z61/did_t...](https://www.reddit.com/r/AskHistorians/comments/6b1z61/did_the_german_people_know_about_the_holocaust/)

</comment></comment></comment></comment><comment><USER15> Saudi Arabia's artificial famine in Yemen has been subject to a worldwide media blockade for well over a year.[1][2] This has taken the shape of systematic under-reporting, preposterously low accounts of the death toll - usually treating the hundred of millions of children dead from famine as collateral damage, or avoiding the subject entirely - whitewashing of the motivations of the conflict and obscuring of its trajectory.

As Gary Brecher pointed out earlier this year, it's not that these stories don't sell. Mainstream news media was rife with accounts of starvation in war- torn Syria in years past:

> But the hundreds of thousands of verified, real famine and epidemic cases in > Yemen get very little coverage. There's nothing subtle about why not. The > Syrian Sunni jihadis were de facto allies of the US/UK/Saudi/Israel/UAE > bloc. So their suffering needed to be amplified. The Shia Yemenis can be > slandered with one word: "Iran." Anything touched by Iran, for Anglo media, > is inherently evil, and anything done to those so tainted needs no further > justification. The "Houthi," i.e. the Shia of NW Yemen, are allegedly > puppets or proxies for Iran, the Shia Mister Big of journalistic > imagination, and therefore legitimate targets for even the nastiest war of > extermination (such as by hunger and disease).

Now, at this late date, we have the New York Times's first real reckoning with Saudi Arabia's crimes. Not only that: there's meta-reporting on the story's traffic on Facebook[3], a self-lauding post about the NYT's audacity in shedding light on the tragedy[4], and an op-ed from Bernie Sanders[5]. All in the course of a few days!

What changed?

Consider this rare moment of introspection from the New York Times: "The tragedy in Yemen did not grow out of a natural disaster. It is a slow-motion crisis brought on by leaders of other countries who are willing to tolerate extraordinary suffering by civilians to advance political agendas. And yet somehow the vast catastrophe has failed to catch the world's attention as much as the murder of a single man, the Washington Post columnist Jamal Khashoggi, in the Saudi Consulate in Istanbul."

From a Saudi standpoint, there was nothing out of the ordinary about Khashoggi's murder. The Saudi Arabian legal system is not codified and has no system of judicial precedent; royal decree trumps the system as a whole (so long as it putatively follows Sharia Law); capital and corporal punishment are both common - beheading and flogging in particular. Freedom of speech and press are anathema.

From a worldwide media standpoint, Khashoggi's kidnapping murder was exceptional. He was one of their own. With his murder, the Saudis broke the devil's bargain they had maintained with worldwide media for years - the one that had (bafflingly) cast MBS as a great reformer and Saudi Arabia as an emerging Silicon Valley of the middle east. The question now is whether this contract can be rehabilitated - and if so, how.

The social dynamics of the reporting on this tragedy should serve as a warning to all of us. Stories like the OP don't get published in a vacuum.

[1] [https://www.nakedcapitalism.com/2018/06/war-nerd-anglo- ameri...](https://www.nakedcapitalism.com/2018/06/war-nerd-anglo-american- medias-complicity-yemens-genocide.html)

[2] [https://www.moonofalabama.org/2017/11/yemen-having-lost- the-...](https://www.moonofalabama.org/2017/11/yemen-having-lost-the-war- saudis-try-genocide-.html)

[3] [https://www.nytimes.com/2018/10/26/business/facebook- blocks-...](https://www.nytimes.com/2018/10/26/business/facebook-blocks-nyt- yemen.html)

[4] [https://www.nytimes.com/2018/10/26/reader-center/yemen- photo...](https://www.nytimes.com/2018/10/26/reader-center/yemen-photos- starvation.html)

[5] [https://www.nytimes.com/2018/10/24/opinion/bernie-sanders- sa...](https://www.nytimes.com/2018/10/24/opinion/bernie-sanders-saudi-arabia- war-yemen.html)

<comment><USER16> > preposterously low accounts of the death toll - usually treating the hundred > of millions of children dead from famine as collateral damage

Quick google puts the population of Yemen at about 28 million. This immediately makes me suspect everything else in your comment is exaggerated or false.

<comment><USER15> Yeah, big typo there - should have said hundreds of thousands (as indicated in the sources cited, including the OP) - but too late to edit now :)

I'm not sure even World War II had a death toll that high.

<comment><USER17> 50 Millions</comment></comment></comment></comment>


Ask HN: Is Keybase a reasonable solution for storing private keys/recovery words - <AUTHOR> I know the safest option is to not store anything online, but considering the probability of losing physical documents, I'm willing to the make the risk/reward tradeoff.
Keybase looks like an attractive option for encrypted cloud file storage. It is end to end encrypted and looks to be a security first platform. What are the attack vectors here? I like that only trusted devices can issue keys to new devices (meaning that even if my Keybase account password is compromised, the hacker still needs physical or remote control of one of my devices to grant file access on their computer).
Physical access is a problem, so a stolen laptop + knowledge of my password could screw me, but I use a lock screen, keep Keybase logged out at all times, have encrypted HDD, etc.
On top of that, I could also encrypt a .dmg file with another password and store that.
Opinions appreciated. <comment><USER2> I use keybase to store a keypass db locked with a yubikey and a passphrase. I have a backup yubikey, and a paper backup in a sealed envelope in a safe to recreate the required yubikey. I also keep the pass phrase in a different keypass db. When i write it out it definitely sounds a bit like 'turtles all the way down.'

I now store a backup of that keypass db, because there was a very short inability to mount the private keybase directory which had me quite nervous and feeling foolish for not already having a backup.

</comment><comment><USER3> I have been pretty happy with the level of security keybase offers. For example, this HN account got hijacked, and I immediately got a notification from keybase.

As you said, nothing's perfect, but it's quite secure esp. compared to many alternatives, and I'd have a hard time thinking of one that offers a similar level of convenience to go with it.

<comment><USER4> What was the cause of keybase notifying you? Was someone trying to breach the keybase account from information from HN?

<comment><USER5> Not GP but my guess is the attacker removed the proof from his HN profile, and KB sent him an email to let him know.

<comment><USER3> Yes, that's exactly what happened. It would have taken me much longer to notice it myself.

</comment></comment></comment></comment><comment><USER6> One threat with Keybase is that an adversary can wipe all data on your account if they just have access to your email (see [https://keybase.io/#account- reset](https://keybase.io/#account-reset)).

I haven't looked into it in detail but Tarsnap might be preferable.</comment>


Posterous (YC Summer 08) launches search for every Posterous blog - <AUTHOR> http://blog.posterous.com/a-search-box-for-your-posterou

<comment><USER2> So are you guys going to launch every feature on Hacker News? Think about it when every startup starts launching their each feature announcement on Hacker News?

Just because you are a YC alumni startup, does it make sense to launch every feature here?

Another thing which annoys me about YC startups is - to get immediate attention, they add "(YC Summer/Winter 08/09)" in the title of their post, and other YC alumni vote up immediately. And the post comes to the front page. I'm tired of these tricks!

Please, there are many startups launching many features every single day. Launching search feature is not a news. Launching a startup is a news. So I would appreciate if you can limit such releases to your blog only. If we are interested, we will follow your blog for feature releases.

Please don't take this personally. I meant this to all YC alumni startups who launch features as if it's a big press release on Hacker News using all above mentioned tricks.

Anyway, it was my $0.02s. Hope you agree to it.

<comment><USER3> Startups making progress and launching new features is my second-favorite thing to read on news.yc. New startups launching is less interesting.

My favorite thing to read is user feedback on new features.

<comment><USER4> I think new startups launching is more interesting than new features, but I do think new features are great to hear about.

</comment></comment></comment><comment><USER5> My small advice to Posterous team on search:

1- Work more on equimatch before doing the partial match. e.g.: if I type 'ruby on rails' you should worry about returning post with 'ruby on rails' first before partial matches. In your case the second and third results do not even have occurrences of 'ruby on rails'.

2- Your match text algorithm, the one responsible of coloring match text on result in green should focus more on full match for now until you find a way to do partial match effectively. One hint, use a regular expression algorithm, that's all the help I can give you for now.

Overall you guys are doing a great job.

edit- One more thing here, if I search for 'iness' you return 'business'. This tells me that your going the wrong way on search. You should do more research on the subject of search.

<comment><AUTHOR> We used to do prefix and infix search, but the amount of value provided was not huge. It also really blows out your indexes / indexing time. I'd like to add this back at some point, but we're not there yet.

As for supporting equimatch using quotes -- its actually not too hard to do this. Just wanted to ship early and iterate rather than expend too much effort getting it perfect.

A plan violently executed today is always better than a perfect plan executed weeks in the future. But thanks for the feedback -- these are important search items that need to be addressed.

<comment><USER5> If I search for 'iness' and you return 'Business' I wonder what your index look like. If it is what I think, you are going the wrong way rantfoil. This will be very time consuming if you are doing it from scratch; it is worth looking at Sphinx as thorax suggested or any open source.

<comment><AUTHOR> Oh, we do use Sphinx. It's excellent. It would be insane to write your own full text searching or rely on MySQL's built in indexing.

</comment></comment></comment></comment><comment><USER6> Has nobody told posterous yet that they need to provide themes for the pages? If I were them, that would be the number 1 priority, not search.

<comment><AUTHOR> Themes are something we have to get right -- we've got about half a dozen themes already designed and we're starting to work on the feature in the coming weeks.

Though I venture to guess early facebook users may have asked for themes for parity with MySpace, and it didn't turn out to be such a big deal in the longer run.

Thanks for the feedback -- you're right that it remains an important feature.

<comment><USER4> Well, for my part, lack of visual customization is the sole reason I don't use Posterous for everything I blog. You reeled us in with cool tricks, but I'm not sure how I can ever make it my core blog if it can't improve visually.

It's also one of the key reasons I haven't yet recommended it to my friends who aren't early adopters. My less tech-savvy friends who use LiveJournal and Myspace see the service more as a geek toy. I showed my wife how easy it was to get content added and she loved it-- but she'd never tell anyone to actually go there unless she can put her personality onto the page.

For my part, I don't care so much for custom pre-built themes-- I just need a way to add my own CSS.

And then I see responses that don't agree that this is the #1 thing on Posterous's plate and it makes me sad as a user. I know how unfun that kind of customization is to code, so the geek in me can relate 100%-- yet speaking as a user, let's just get this feature already and let that be the one I see announced on HN.YC instead of these other cool features you guys want to add.

Keep up the good work, though. You guys make good stuff, no doubt.

<comment><AUTHOR> Many thanks thorax -- this is the feedback we need to hear.

</comment></comment></comment></comment><comment><USER7> Have you thought about putting a search bar on the main page? Or do you think that will take away from the ease of posterous?

Also, wouldn't you want the explore search bar: <http://posterous.com/explore/>

to look like this one: <http://posterous.com/explore/?search=garry>

Finally, on the explore page I think it'd be cool to have a running sidebar of the most recently updated posterouees (sp?).

<comment><AUTHOR> Dan, awesome ideas man.

For the homepage, one thing we obsess about is keeping the choices dead simple obvious. (see tyranny of choice problem) We want people to try posterous, and I'd be worried a search box would be pretty distracting.

But the rest makes a ton of sense.

<comment><USER8> I second the "most recently updated" list on the Explore page.

</comment></comment></comment><comment><USER9> I think Posterous has some excellent features going. What it doesn't have is a community feel behind it. I get the feeling that every Posterous blog stands alone. Versus other blogging systems - Tumblr comes to mind - where community is a big part of the fun. That's one of the things that's made Posterous tough to consider as a main platform - that and theming.

<comment><USER8> What do you mean? You can't even comment on a Tumblr! There is no community there by design.

<comment><USER9> Are you a Tumblr user? Because the large part of the community occurs on the Dashboard, through reblogging and passing things along. You get some people who comment back-and-forth, some people who act as nodes for large amounts of content. I'd love to map it: you get a brilliant web built up.

Tumblr isn't about the individual blog community. It's about the _Tumblr_ community. And I like, actually, that when you look at a blog it seems entirely personal, but that from the dashboard it seems like parts of a larger community.

Also: see <http://tumblelog.marco.org/61329864>, where you can see the actions of an item in the community. They've also beta-tested a "questions" module, which you can see here: [http://www.davidslog.com/58675697/where-should-i-get- cupcake...](http://www.davidslog.com/58675697/where-should-i-get-cupcakes-in- williamsburg)

The Tumblr founders are very against comments, and I _love_ that. Comments don't form a community. They add a facade of a community in all but the best cases. Community relies on the form of the medium, and commenting very rarely is the answer. With forums, you have threads; with Tumblr, you have likes, reblogs, and answers. It's a wonderful solution.

<comment><AUTHOR> The concept of bubbling up conversation to the top level of one's own published blog is fascinating. I didn't quite understand reblogging before reading your explanation, and I think that's the main downside to the scheme, but there is certainly value in making the act of commenting ALSO an act of publishing on one's own blog.

<comment><USER9> Yeah. It's tough to understand, and sometimes I feel that it detracts from the blog entirely (extended back-and-forth conversations start to look amateur), but it's a very neat system that gives you a lot of freedom in how you choose to handle interaction.

</comment></comment></comment></comment></comment><comment><USER10> I just tried posterous -- it seems wierd that you don't need to sign up to create a blog, but do to comment on one.

<comment><AUTHOR> 100% anonymous comments are an option that can be turned on by the blog owner.

When anonymous comments are enabled, we run those comments through akismet and some other spam detection logic, but for many people, they just don't want the hassle.

</comment></comment><comment><USER11> What was Posterous developed in?

<comment><AUTHOR> Ruby on Rails + special sauce

<comment><USER12> what did you use for search?

custom or acts_as_xapian/ferret/solr ?

Curious cause we had a discussion of rails search at the last local rb meetup

<comment><AUTHOR> Was using sphinx + ultrasphinx, but was talking to Evan Weaver the other day and he mentioned thinking_sphinx is the one to use now since Pat Allan is really intensely working on it, so we switched over to that in this release.

Note: For larger production websites served off multiple app servers, thinking_sphinx doesn't work well since it tries to do reindexing of changed items directly within the rails process. However, there is a great fork of the latest plugin that can use updated_at, so you can index your deltas on a cronjob, offline. Check it out if you're going to use thinking sphinx: [http://blog.edhickey.com/2008/09/15/thinkingsphinx-rails- plu...](http://blog.edhickey.com/2008/09/15/thinkingsphinx-rails-plugin-fork/)

</comment></comment></comment></comment><comment><USER13> neat application</comment>


Common Mistakes I See Founders Make Over and Over Again - <AUTHOR> http://blog.fullstack360.com/post/134693547565/the-horror <comment><USER2> 1) Build Build Build

The MVP is a pretty well established item nowadays, this was much more true in the past but people have caught up to this long ago.

2) Fully Outsource Development

No start-up that I'm aware of would outsource all of their development, in fact, I don't recall a single time over many years of a start-up that outsourced any development at all. Are there many examples of such start-ups?

3) The wrong technical cofounder

This I've seen. But I've also seen: the wrong person for sales and marketing, the wrong person for the CEO role, the wrong person for finance and so on. Start-ups are risky in part because there is a chance that one of the founders will not work out and that could easily kill the company if not detected and contained early enough. But that goes for any role, not just for the technical lead, and not more so for the tech lead than any of the others.

4) Spend, Spend, Spend

For that you have to have money first and most start-ups never get to the stage where they do and the ones that do usually have a bit of supervision on that account once they get the 'big bucks'. During the .com boom this was different but nowadays start-ups are a lot more conservative when it comes to their spending than in the past.

All in all this essay would be more applicable 16 years ago than today.

There are common mistakes that founders make over and over again but these aren't as common in my experience. Maybe that's a geographical artifact.

A couple of common mistakes that I do see: failure to communicate clearly and often between founders, failure to accept responsibility, culture of blame, lack of preparation for changing circumstances, lack of proper definition of expectations, founders being in different phases of their lives with different risk profiles, NIH, trying to be both a platform _and_ an application on that platform and so on. These I've seen, recently, and more than once and each and every one of those has the potential to wreck a start-up, even in a later phase.

<comment><USER3> Re #2 - fully outsourcing development. I've seen this done successfully and as a matter of fact I was on the team that built the first MVP. I'm sure it's the exception and not the rule but it can be done if the team that's brought in is super professional and talented. (We were). There are some benefits to this route if done correctly

1\. The code left for the eventual, internal, team is pristine, well written, scalable and easy to jump into. 2\. Well defined processes are in place. 3\. Our company helped find, introduce, and often interview the new employees for our client.

It's worked out well several times but it's certainly not cheap. You get what you pay for.

<comment><USER2> Very neat, you should definitely do a write-up on that, it is super interesting that you found a way to do this.

<comment><USER3> A former coworker did a write-up and an interview with one of his former clients and I think it sheds a lot of light on how this can work - [https://robots.thoughtbot.com/a-client-project-two-years- lat...](https://robots.thoughtbot.com/a-client-project-two-years-later)

<comment><USER2> I've been reading that for an hour or so now, you could easily get another 'Soul of a new machine' out of your project. Maybe not as dramatic but that project could easily serve as a benchmark of outsourcing done right. I'm going to sleep now and I'll re-read it tomorrow. Thank you very much for that link.

</comment></comment></comment></comment></comment><comment><USER4> One common mistake is: having too much passion and refuse to pivot. This is somewhat a grey area. First, your idea might not be even new and there are many competitors or alternatives (which is more dangerous than direct competitor). Then you end up convincing yourself: yeah, I will be the next Dropbox. Their idea ain't new. Second, even if it is a new idea, you tend to see many problems along the way in term of market adoption. You refuse to change / pivot. You will fall into the circle of denials because you think your product is not up to the mark yet.

<comment><USER5> There's actually a commonly repeated lesson there (although I forget the popular source) -- You should have passion for the _problem_ , not passion for _your_ solution to it. If you're passionate about the problem, and it's a real one (it's unlikely you can be passionate about an imaginary one), there's no such thing as too much passion. If a solution you worked on for hundreds of hours isn't the right one to solve the problem you're passionate about, that passion will overcome your attachment to the solution and you'll be willing to pivot.

Have passion for the problem, and even if other people have attempted to solve it, your passion will help you solve it better than them even.</comment></comment>


Using Hugo, Gitlab Pages, and Cloudflare to Create and Run a Free Static Website - <AUTHOR> https://tkainrad.dev/posts/using-hugo-gitlab-pages-and-cloudflare-to-create-and-run-this-website/ <comment><USER2> So far as I can see github pages supports ssl termination with let's encrypt certificates all by itself:

[https://github.blog/2018-05-01-github-pages-custom- domains-h...](https://github.blog/2018-05-01-github-pages-custom-domains- https/)

<comment><USER3> Let's Encrypt for GitLab pages should be coming in the next release though (finally). It's been in the works forever.

Edit: source [https://gitlab.com/gitlab-org/gitlab- ce/issues/28996](https://gitlab.com/gitlab-org/gitlab-ce/issues/28996)

</comment></comment><comment><USER4> I have also chosen gitlab, hugo and netlify. Netlify because they have the nice feature to use forms in the site. My setup is described in this post. [https://www.me2digital.com/blog/2017/09/move-from-wp-hugo- an...](https://www.me2digital.com/blog/2017/09/move-from-wp-hugo-and-netlify/)

</comment><comment><USER5> Nice Work! I'd will check out GitLab pages soon!

I just wrote a guide on how to migrate from Jekyll-HPSTR to HPSTR-Hugo.

This in-detail guide should help anyone switch from Jekyll to Hugo or even Hugo to Jekyll.

I didn't notice this before posting:

[https://news.ycombinator.com/item?id=20070203](https://news.ycombinator.com/item?id=20070203)

Direct Link- Migrating from Jekyll-HPSTR to HPSTR-Hugo:

[https://infominer.id/web-work/posts/migrate-jekyll-hpstr- hug...](https://infominer.id/web-work/posts/migrate-jekyll-hpstr-hugo/)

</comment><comment><USER6> What is a good way to get analytics and comments in such a set up ?

<comment><USER7> Not OP, but you can embed Google Analytics (or Tag Manager) into your Hugo template, and it's fairly straightforward to do.

Comments I'm not entirely sure of, because I never wanted them on my site in the first place!

<comment><USER8> For comments you can embed an external service, like Disqus.

<comment><USER7> Agree! And I'm sure it's also another script to add to the templates, at the footer of a post template, probably?

</comment></comment></comment></comment><comment><USER7> Guess it's having connectivity issues?

Haven't read the post yet, but any advantages to using Gitlab Pages and Cloudflare with Hugo over using Netlify?

My personal blog[0] is Hugo + Netlify, and it's been a pretty great experience, so I'm always curious about alternatives! (I'm not a fan of the Netlify CMS though.)

[0] [https://jonlim.ca/](https://jonlim.ca/)

<comment><USER9> the main advantage for me is that Cloudflare's free tier has no bandwidth limit. Netlify's free tier has a 100GB/month limit ([https://www.netlify.com/blog/2019/02/26/netlify-and- bandwidt...](https://www.netlify.com/blog/2019/02/26/netlify-and-bandwidth/)). I put Cloudflare in front of my Netlify site because of that.

<comment><USER10> Or instead spend some time to optimize your website a little (like not hosting yourself standard stuff like jquery, Bootstrap and such, compress images, etc). So you can serve 10s of 1000s visitors without hitting a 100 GB free tier ;-)

<comment><USER11> You're responding to someone running one of the more well-known developer blogs and hosting PDFs, it's not exactly surprising she might need a bit more bandwidth.

</comment></comment></comment></comment><comment><USER12> I used to rely on Github + Cloudflare, but now services like netlify.com are a a simpler/better alternative.

EG netlify gives you a Docker based build environment + CDN, all you need is a a Github/lab repo with a config file.

<comment><USER13> Gitlab gives you a build environment with a choice of several static website builders. Personally I'm using Hexo rather than Hugo and it "just works".

</comment></comment><comment><USER14> How can you avoid content dupe for search engines?

<comment><USER15> What do you mean?

<comment><USER14> Gitlab (this is where you host the content) Gitlab Pages and Cloudflare are public-facing. If e.g. Google starts caching, for Gitlab Pages you might be able to set the canonical tag to point to the CloudFlare-served hostname, but I am not aware how to do it for the Gitlab UI.</comment></comment></comment>