The cost of forsaking C - <AUTHOR> https://blog.bradfieldcs.com/the-cost-of-forsaking-c-113986438784 <comment><USER2> Knowing C has made me a better and much more versatile programmer than I would be without it. For instance, a while back I had to diagnose a JVM core dumping sporadically, and I was able to use my knowledge of C to try to recover valid return addresses from a corrupted stack, figure out there was a signal handler block on the stack, then further unwind from there to find out the whole story of what likely caused the crash.

Knowing C also helps me write more performant code. Fast Java code ends up looking like C code written in Java. For instance, netty 4 implemented their own custom memory allocator to avoid heap pressure. Cassandra also has their own manual memory pools to try to improve performance, and VoltDB ended up implementing much of their database in C++. I've been able to speed up significant chunks of Java code by putting my "C" hat on.

I would recommend every college student learn C, and learn it from the perspective of an "abstract machine" language, how your C code will interact with the OS and underlying hardware, and what assembly a compiler may generate. I would consider learning C for pedagogical purposes to be much more important than C++.

<comment><USER3> Can it be replaced with Rust nowadays? Is it low-level enough? Or borrow checker and lifetimes defeat the whole purpose?

<comment><USER2> For teaching purposes in a university I don't know if rust would be better or not. Keep in mind that the goal isn't necessarily to learn C the language; it's to learn enough of the core language to explore things like:

* How the code is executed on modern hardware and operating systems.

* How various language features might be compiled to assembly

* Memory layouts for things like stack frames, how a simple heap allocator might work, array layouts, layouts for other structures like linked lists, etc.

* The relative cost of various operations and how to write code that is cache friendly.

* How debuggers generally work and how to debug code.

Could these things be taught equally well or better in an undergraduate seeing using rust? Honestly I don't know; I know very little about Rust. I can say that I think C++ is a worse language for this purpose because of the language's complexity and because of features that aren't well suited for the above purposes.

I have heard, for instance, that's it's actually very difficult in rust to write a linked list without dropping to unsafe code. I would consider this a bad thing for the above purposes.

<comment><USER4> > * How the code is executed on modern hardware and operating systems.

Does _anyone_ know this at this point? With pipelining, out of order execution, vectorisation, register renaming, speculative execution, buffered micro-op fusing and what have you, it's very hard to say general things about how the code executes on the actual hardware.

<comment> yjftsjthsd-h Perhaps, "Understand the model of how code pretends to be executed"? Pipelining, etc. are meant to produce the same results as the older/simpler systems. You need to understand that that's not quite reality anymore, but as a basic model it's fine.

<comment><USER4> Sure, but at that point you are content with learning "the x86 virtual machine" \-- and is that fundamentally different from being content with learning "the Java virtual machine"?

I'm arguing that it's a matter of degree, not of kind. People make it seem like it's the latter.

<comment><USER5> It's different in kind. The JVM completely abstracts away things like class loading from the perspective of bytecode - that stuff seems to happen like magic. Ditto exception handling, stack frame linkage, memory allocation, etc.

Viewing all of code and data living together in a big array is important, I think. You don't understand e.g. dynamically generated thunks and shims without seeing the duality of code and data at the execution level.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> If you want to "think like a computer" then learn assembly, not C. I'm not joking.

In my experience young devs using C get very confused about wtf pointers are really about and what's the deal with the heap, stack, etc. Whereas they understand the concepts better in assembly despite the verbosity.

I'm not arguing for a deep understanding of assembly but if the goal is to "think like a computer" than at least a basic understanding is incredibly helpful. Or at least less confusing than C.

<comment><USER7> I partly agree with you. But its a fact that you can't just start learning assembly if you have never learned C in the first place. So, young devs, please start learning C first.

<comment><USER8> This is false. I _have_ learned the basics of assembly without knowing C first. My experience before learning assembly was: Java, Python and some Objective-C (without knowing pointers). So if your point is that you need to learn programming first, then maybe that is true but I highly doubt it. But I can't refute that with my own experience.

Here wa my roadmap:

(1) I first learned assembly by learning computer architecture from Tanenbaum's book -- Structured Computer Organization -- and related course at the Vrije Universiteit Amsterdam. This taught me a toy architecture (Mic1) but it give me a rough idea of how assembly worked.

(2) Then, later I took a course in binary and malware analysis and all that we were required to do was to read x86 assembly in IDA and interact with it via GDB -- and using the command: layout asm, which gives a layout for all the register values and upcoming instructions.

And once I have a debugger available and understand it well enough, I can learn quite well since I can make little predictions and check if they are right or wrong, and so on.

<comment><USER9> I learned assembly as my first ever programming language and it was just fine. Assembly tends to be simple and can get you coding quickly and understanding the machine as well. It's of course an awfully inefficient way to code in general and that's why we have HLLs but its not true that you need to learn at least one HLL before learning assembler.

</comment></comment></comment></comment><comment><USER10> C is tightly coupled and co-evolved with the Von Neumann architecture. If you understand C you can better understand _that_ architecture, but it's far from the only one. Beyond the world of single core CPUs, systems rarely hyper- specialize to the point that the C/Von Neumann system has (focusing all energies on ALU throughput). And the larger (and more distributed) systems we build, the less they resemble Von Neumann machines.

So while it's realistic to embrace C for many tasks, it's wrong to convince yourself that "the rest follows" from C.

<comment><USER11> Can you recommend some non-Von Neumann architectures worth learning about? Maybe you agree with these suggestions I found by Googling, or maybe you have other ideas: [https://stackoverflow.com/questions/1806490/what-are-some- ex...](https://stackoverflow.com/questions/1806490/what-are-some-examples-of- non-von-neumann-architectures)

<comment><USER8> I second this, I want to know some recommendations too. Are there university courses out there that teach non-Von Neumann architectures? And what are the application areas? I could Google myself but my experience with HN is that if someone knows a good course, then it is a good course. While with Google, not so much.

<comment><USER12> The Mill architecture:

> the mill uses a novel temporal register addressing scheme, the belt, which > has been proposed by Ivan Godard to greatly reduce the complexity of > processor hardware, specifically the number of internal registers. It aids > understanding to view the belt as a moving conveyor belt where the oldest > values drop off the belt and vanish.

[https://en.wikipedia.org/wiki/Mill_CPU_Architecture](https://en.wikipedia.org/wiki/Mill_CPU_Architecture)

</comment></comment></comment></comment><comment><USER13> I still can point to the exact point in my college career that took me to a whole new level of understanding how to program in Java or Python to understanding how things like Garbage Collection, Threads, and other abstractions actually worked. It was an elective I took on Graphics Programming and it was all in C and OpenGL.

Being without GC, I learned the trade offs. Obviously, being able to explicitly allocate and free memory was a big deal. But at the same time, I learned to appreciate the complexity and pitfalls of GC.

Threads are great in Java (as are their parallels in other languages): this is the work to do, put the results here, and everything is cleaned up. Meanwhile, just trying to get the results back from a forked process was CRAZY. Implementing and managing my own shared memory to pass messages back and forth...wtfbbq.

"Think like a computer," not really. More like, "understand what all goes into a thread, an async call, or a garbage collector. Gain more understanding into the corner cases and exactly how much this thing is doing for you. So maybe setting something to null or pre-allocating objects to reduce heap work isn't that big a deal."

C taught me to be patient with higher level languages, to better understand what they were doing for me, be able to reason about how they may be doing these things wrong, and to think critically about how to coax these features into behaving the way I want them to.

Really any lower level language can teach these things. The point here is that C is a nearly universal language that can teach you to reason about these things.

</comment><comment><USER14> I think learning C is a fine thing to do, when the alternative is to learn nothing at all, as knowing C is a quite useful skill. However, a more substantive question should be, "should you learn C next, or R?" or "should you learn C next, or neural networks"? or "should you learn C next, or Bayesian statistics"? It may be that C is more urgent and important to learn than any of those, but if you find that people are not, it is not necessarily the case that they don't see the usefulness of it. They may just have a finite amount of time, and learning Mandarin Chinese ranks higher for them, not least so they can better understand how natural language processing would work if you're involved with non-European languages.

</comment><comment><USER15> By all means teach and use C (I do!), but please teach students to refer to C11 or C99, not C89.

<comment><USER16> Yes. At least C99.

Also, the blog throws in "and C++" in parentheses. C++ is another beast altogether -- it diverged from C a long time ago -- read Scott Meyer's "Effective Modern C++" if you think C and C++ bear any resemblance.

</comment></comment><comment><USER4> I feel like this article makes two strong arguments in favour of C:

1\. You need to know C because C is popular, and

2\. You need to know C because C is a lowish-level language.

I can't very well argue with the first point -- indeed, nearly everything fundamental is made in C or the C-like subset of C++ still -- but I oppose myself to the second.

I do think you should learn a lowish-level language, but there are good reasons to make that language something like Ada instead; something high-level enough to have concurrency primitives yet low-level enough to force you to consider the expected ranges of your integers and whether or not you want logical conjuctions to be short-circuiting. Something high-level enough to have RAII managed generic types, yet low-level enough to let you manipulate the bit layout of your records. High-level enough to have exceptions and a good module system for programming in the large yet low level enough to have a built in fixpoint type and access to machine code operations.

Unless you target C specifically for its popularity, there are other options out there, filling the same gap.

<comment><USER17> >>Ada instead; something high-level enough to have concurrency primitives yet low-level enough to force you to consider the expected ranges of your integers

In practice Ada programmers, because they actually have a proper method of expressing integer ranges, are going to be much more considerate of such things.

</comment></comment><comment><USER18> C++ and Rust address most of the issues presented in the article (with the exception of being able to read the source code of existing software).

My very controversial opinion is that C is obsolete for new programming projects. For example, everything that C can do, C++ can do and better/safer/faster. Rust is also getting there (if not there already). C is not Pareto optimal anymore.

<comment><USER19> Maybe depends on the project. Writing a web API in C almost certainly isn't pareto-optimal. A linux/raspberry-pi driver for your hobby-project that needs to interact with other low-level linux-based software however, C is probably the most efficient fit.

Rust (and maybe Go) do seem like very good long-term replacements for C, but imho it's too early to say that. Until there's a "full stack" of software (OS to user-space/desktop), you still kinda need to know C if you want to be able to understand how your whole computer works.

<comment><USER20> I don't see Go as any sort of replacement for C. The fact that it's garbage- collected means that it's really not suitable for use in embedded or kernel programming.

AFAICT, Rust was created to be a safer C, and Go was created to be a faster Python; completely separate domains.

<comment><USER19> You're quite right.

</comment></comment></comment></comment><comment><USER21> _C is so unfashionable that the authors have neglected to update it in light of 30 years of progress in software engineering._

Words escape me.

<comment><USER22> Out-of-context quote. (Even if the original is slightly strangely written.) The "update it" refers to the _book_ The C Programming Language, not to the C language itself; C itself has seen an update as recently as 2011.

<comment><USER17> It's not out of context at all. It's bizarre to assume that every book ever written about a subject will be updated constantly by it's (currently septagenarian) authors in perpetuity and/or that a failure to update it is an indication of the culture in general and not the authors having literally anything else to do.

It's not like books on C stopped being written by 1990.

<comment><USER23> Yes, but _The C Programming Language_ is almost always recommended as _the_ book to read.

</comment></comment></comment></comment><comment><USER24> > Forsaking C means forsaking anything below the level of abstraction at which > one happens to currently work.

That's trivially true. Pick anything as your bottom abstraction layer, you can almost certainly find something below. Unless you're working on the foundations of mathematics or trying to come up with theories of quantum gravity you haven't hit the bottom of the abstractions.

It's also not as though C is the bottom layer even for programming. There's assembly. Then HDLs like Verilog or VHDL. Then electrical engineering... You have to stop somewhere. My knowledge spans from some electrical engineering through C up to Python/Java/Lisp levels, but I don't (currently) know much of anything about Javascript or actual semiconductor engineering or more than basic physics...

C is pretty good as a foundation for programmers. It's terrible as a foundation for computer engineers, and it's pretty much at or above the ceiling for what's expected of electrical engineers. It's not guaranteed to remain a good foundation for programmers. Massively parallel architectures like GPUs don't tend to fit well into C's abstract machine model.

</comment><comment><USER25> > Forsaking C means forsaking anything below the level of abstraction at which > one happens to currently work.

This is mostly true today, but I hope that over time we'll see more languages fill the gap between hardware and high-level languages. There's no fundamental reason why that middle layer has to be in C, we just have had a shortage of viable alternatives.

<comment><USER26> There's no shortage of viable alternatives. C++ is significantly more popular than C these days, and the gap widens every year.

<comment><USER27> The problem is you can't learn all of C++. I've been coding in it for the better part of a decade and I still run into weird corners that don't make sense regularly.

C is much more compact.

<comment><USER16> Amen. Every time I think I have my head wrapped around C++ a new version comes out or Scott Meyers writes a book and I realize how ignorant I am about C++. No one really know all of C++.

I bet Stroustrap occasionally sees some C++ code and says "huh ... I didn't know you could do that."

<comment><USER4> > "huh ... I didn't know you could do that."

To be fair, that is not an entirely uncommon thing to say when watching a user work with something you made.

</comment></comment></comment></comment></comment><comment><USER28> I've heard C language was designed with the idea that the programmer knows what he is doing and the programming language shall not be standing in his way.

For me the cost of forsaking C would be not to experience 100% programming freedom/power (which comes with 100% responsibility). And yes, C also gives you the freedom to do any nonsense :)

I was always fascinated how little resources are needed to run C programs, here an example (not by me): [https://github.com/barteksalsa/avr- tiny12-disco/blob/master/...](https://github.com/barteksalsa/avr- tiny12-disco/blob/master/leds.c) ATTiny12 mikrocontroller with: 1 KiB program flash rom, 32 bytes of "ram", 3 level hardware stack

<comment><USER29> The infamous quote goes

 _" The C language combines all the power of assembly language with all the ease-of-use of assembly language."_

<comment><USER28> Do you have a specific example? I wrote programs in Z80, AVR, x86/amd64 and MIPS assembly. In my experience writing C is MUCH easier.

<comment><USER29> But C allows for just as much foot-shooting, thus the joke. (The quote is meant to be humorous)

</comment></comment></comment></comment><comment><USER17> C does not help you think like a computer. It has no language level support for memory hierarchies or parallelism. It doesn't about know about integer overflow.

<comment><USER30> While I disagree with your other claims, I'm especially curious about this one:

> no language level support for memory hierarchies

By this, I assume you mean cache hierarchies (for example). What languages do?

<comment><USER17> None other than various assemblies thanks to the "influence of C" convincing people that a flat (essentially contiguous) endless memory space was "how a computer works"

<comment><USER31> Typical assembly languages hardly do anything more with cache hierarchies than C does.

</comment></comment></comment></comment><comment><USER32> No mention of Forth? Small, close to the metal, easier than C, and just as capable. But it's from that alternative universe of computing (also inhabited by Lisp and Smalltalk).

A couple of well-known articles/discussions about that universe:

A Forth Story: [https://news.ycombinator.com/item?id=3813966](https://news.ycombinator.com/item?id=3813966)

Lisping at JPL: [https://news.ycombinator.com/item?id=7989328](https://news.ycombinator.com/item?id=7989328)

</comment><comment><USER33> I know these guys and they provide legit college-level CS education. If any of you live in the bay and have an education stipend at work, or just want to level up, then I highly recommend.

</comment><comment><USER34> Most of the C language texts that I have come across just seem to teach how to use the language, say pointers etc. Maybe there is something about how to use make.

I've found it hard to go from there to link up with the more abstract stuff. Not so with python, because the mental energy I spend reading python code is very little, which enables me to move very fast.

Reading sklearn source has been a revelation to me. I can't imagine having to read a similar high level equivalent in C.

</comment><comment><USER35> TL;DR

      We give students four reasons for learning C:

      1. It is still one of the most commonly used languages outside of the Bay Area web/mobile startup echo chamber;
      2. C's influence can be seen in many modern languages;
      3. C helps you think like a computer; and,
      4. Most tools for writing software are written in C (or C++)

[Not really TL, but good context for reading comments referencing the numbers]

</comment><comment><USER36> > There isn't even a cute C animal in C's non-logo on a C decal not stuck to > your laptop.

At least there is a cute image presenting "The C Programming Language" in the context of Plan 9: [http://9front.org/img/000000wq9nh.png](http://9front.org/img/000000wq9nh.png)

<comment><USER37> I guess Cirno counts, her name starts with C!

</comment></comment><comment><USER38> for rubyists and pythonistas interested in writing more C while not losing the convenience of scripting, lua is probably worth picking up along the way. the following is the C-interop samples from Programming in Lua

[https://github.com/ransomw/exercises/tree/master/lleaves/plu...](https://github.com/ransomw/exercises/tree/master/lleaves/plusc)

... only gripe with this article is the couple of "... and/or C++" clauses: i personally hope to be forgiven for forsaking C++ for new projects, because it is not the 1970's anymore, and i suppose there are alternatives for almost every use case as well as externs for plain-C interop with existing C++ libs.

it's more like C+{100} so many are the additional feature-ughs.

</comment><comment><USER39> This is a really fun (and relatively short) c programming book: [https://www.amazon.com/Expert-C-Programming-Deep-Secrets- ebo...](https://www.amazon.com/Expert-C-Programming-Deep-Secrets- ebook/dp/B00E0LASCU/)

<comment><USER40> This book is really good, and I'd say that a couple of weeks after reading K&R - you should read this one (given that you fiddle with C during those weeks).

</comment></comment><comment><USER41> About not being updated: there are linters, and if you impose a rule that you can only check in code that passed the linter, then essentially you are writing a newer, better version of C.

</comment><comment><USER42> C is like English. You know it without having to grab a book. It just flows out of you naturally.

<comment><USER43> how can one of the languages with the most tricky syntax to parse "flow naturally"?

and I say this as somebody proficient in C.

</comment></comment><comment><USER44> Learn basic digital circuits. Learn an assembly language. Learn C. Implement a simple interpreted language.

You don't have to reinvent every level of the stack and connect it all together(your imagination can fill in the gaps), but this removes the mystery of computing.

</comment><comment><USER45> > _The most recent edition of the canonical C text (the excitingly named The C > Programming Language) was published in 1988_

So... C99 and C11 aren't things?

<comment><USER46> C99 and C11 are things; just not the kinds of things for which you update a classic book that describes a reasonably nice language that some of us still prefer to work with (over those things).

From the K&R2's [1988] Preface:

 _" We have tried to retain the brevity of the first edition. C is not a big language, and it is not well served by a big book"_.

Well, that line would go out window with a C11 update. Along with, from the introductory chapter:

 _C is not a "very high level" language, nor a "big" one, and is not specialized to any particular area of application._

Oops; the page count in ISO C more than doubled.

 _But its absence of restrictions and its generality make it more convenient and effective for many tasks than supposedly more powerful languages._

The absence of restrictions, whereby C programmers were wrestling particular behaviors out of their code with the cooperation from a particular set of compilers, has lately been turned into a license to wreck non-portable code that used to work for decades.

Who wants to update a classic book in the environment in which you have to warn the reader of undefined behavior at every turn.

<comment><USER47> How do you deal with multi-threading in C89? If you rely on POSIX for your threading support, couldn't you argue that you are now dealing with something just as complicated, if not more complicated than C11?

Sometimes there is just unavoidable complexity for extremely useful features like thread support. Keeping stuff like that out of the standard doesn't necessary make the language simpler if you are forced to rely on other standards anyways ...

<comment><USER46> > _How do you deal with multi-threading in C89?_

Certainly not by means of the abhorrent garbage that has been added to C for threading.

POSIX is a standard. POSIX started as a branch of the Unix C library that didn't belong in the language. So for instance that's where "open" and "ioctl" went, while "printf" and "malloc" went to C.

There is no need for C to start adding its own versions of POSIX requirements (let alone toy versions); it just adds complexity.

Now what it means is that we can end up with some mongrel project where we have POSIX threads being spawned in one module, ISO C threads in another and so on.

</comment></comment></comment></comment><comment><USER48> I fail to see how an understanding of C would make one better at understanding userspace process scheduling or text editors.

<comment><USER49> May I kindly lay out VSCode and Atom as a counter to your second example?

Knowing your allocations and performance at a low level can influence usage of a high level language and have a huge impact.</comment></comment>


JSON vs. YAML – try it yourself - <AUTHOR> http://www.json2yaml.com <comment><USER4> This is valid JSON in the same LOC: [http://i.imgur.com/gv79uNM.png](http://i.imgur.com/gv79uNM.png)

It just seems like YAML is making things more implicit. I like explicitness. Not against YAML, but it's no holy grail in my mind.

I'm more experienced with JSON than YAML and could be swayed on this, but so far I'm not. They seem like two roughly equal ways to do the same thing.

This seems oddly similar to the nit-picky problems people have when learning Python from a C-like background and being annoyed that semicolons and flexible indentation aren't the norm. When I spend months working on JS code, looking at Python slightly annoys me, and vice-versa, so I think I get it. I just don't think it's an important, game-changing thing.

I'll be learning about Ansible soon, so I'll have to also learn YAML syntax. I guess I'll have a more educated view once I've gotten deep into that.

<comment><USER5> YAML has a couple big advantages (in the proper situations) over JSON. Self- referencing, complex datatypes, and (my personal favorite) embedded block literals. I've, perhaps unwisely, embedded entire webpages a single indentation level after a variable and retained all of its formatting.

I'm no YAML zealot though, I do use JSON most of the time, but in the past couple years I've started writing most of my config files in YAML where I have the opportunity.

<comment><USER6> We recently moved much of our application's schema definitions and configurations out of code/JSON and into YAML files (we generate JSON during the build process in placess where it is necessary). A pleasant side effect was that the YAML file set began to double as basic documentation.

e.g.

        name: user
        plural: users
        label: User
        ...
        primary_key: uid
        display_key: full_name
        unique_keys:
            - <USER2>
            - <USER3>
        client:
            storage:
                type: IndexedDB
        ...
            actions:
                create:
                    label: Save
                    permission: create_user
        ...
        server:
            storage:
                type: mysql
        ...
            api:
                create_user:
                    url: /users
                    method: post
        fields:
            username:
                name: username
                label: Username
                type: string
                length: 20
                required: true
                editable: false

<comment><USER4> This is very interesting.

So is this the equivalent of multiple JSON documents? I'm looking at:

[http://yaml.org/spec/1.1/#id857577](http://yaml.org/spec/1.1/#id857577) and [http://yaml.org/spec/1.1/#stream/information%20model](http://yaml.org/spec/1.1/#stream/information%20model)

I'm actually having a hard time, even with some google-fu, finding information about how this might be used. YAML->json parsers have failed to handle docs with a '...' separating parts of a document so far. Would this triple-dot structure be used to create multiple JS objects? How would I find more information about how this might be used in practice?

I have a feeling this would be easier to figure out if I just went and played around with it in practice, but it also seems like something that could be documented in more beginner-friendly terms.

I'll probably be kicking myself once I figure it out, but I also only have a cursory understanding of how streams work. Maybe this is an opportunity to fix that. Once I figure it out, I'll respond to this if nobody else has.

<comment><USER7> I think the GP was using '...' as a standard "stuff removed for brevity" ellipsis.

However, since you asked:

In a YAML document, there is an implicit top-level object, either a hash/dict/associative array or a list/array depending on your formatting.

The '...' separates streams, or top-level objects, within a single file or IO stream.

YAML parsers generally stop when they hit the separator, even in languages that can do multiple assignment. If your IO stream behaves like a file handle, you can read it repeatedly into different variables until EOF.

Multiple streams in a YAML document are fairly uncommon. I think most people don't know they exist, but I appreciate the flexibility and use it whenever it makes sense.

</comment></comment></comment></comment></comment><comment><USER8> The stack overflow page is disappointing because in my opinion all of the answers miss the point: Yaml is designed to be readable and _editable_ by humans. Json is only designed to be human readable - and intentionally does not have features to support editing by people.

Json _intentionally_ does not support comments. Think about that for a bit and you'll realise what Json is for and what it _isn 't_ for.

As SeoxyS said: use yaml for config files, Json for APIs.

<comment><USER9> Actually, after finding out about TOML[1], I would suggest to look at it. It is a lot simpler than YAML, explicitly does not support dangerous features like deserializing arbitrary data structures, while being very readable. Spec is not entirely stable yet, though.

1: [https://github.com/toml-lang/toml](https://github.com/toml-lang/toml)

<comment><USER10> Agreed. After using both YAML and TOML, I'd say that TOML is much more readable as compared to YAML.

</comment></comment></comment><comment><USER11> I like both JSON & YAML for different reasons. YAML is a great configuration format; it's fantastic for being read and written by humans. JSON is much better as a serialization format.

Write config files in YAML. Write APIs in JSON.

<comment><USER12> Why is it a better serialization format compared to yaml?

<comment><USER13> it's more explicit.

<comment><USER14> I don't really see how it is more explicit. Can you explain? Because of the braces?

</comment></comment></comment></comment><comment><USER15> Biggest thing about yaml for me was that you can have comments. This is very useful especially when you use it for configuration.

For data interchange, I don't see a lot of advantages to yaml though.

<comment><USER16> One thing that comes to mind is (for data interchange), it allows for custom objects to be explicitly marked as such

[http://www.yaml.org/spec/1.2/spec.html#id2805712](http://www.yaml.org/spec/1.2/spec.html#id2805712)

additionally, it allows multiple top level objects in one file (which JSON can't do (not counting 3rd party modifications))

other than that, not much other use

<comment><USER17> > additionally, it allows multiple top level objects in one file (which JSON > can't do (not counting 3rd party modifications))

That's just different syntax for a top-level list of objects.

</comment></comment></comment><comment><USER18> HHVM (FB's PHP/Hack) moved from YAML (hdf flavor) to INI for its configuration file format. Sad but true, it was just awful to work with - good that they changed it. [https://github.com/facebook/hhvm/wiki/Runtime- options](https://github.com/facebook/hhvm/wiki/Runtime-options)

<comment><AUTHOR> yaml was awful to work with? can you provide explanation

</comment></comment><comment><USER19> YAML IS INSECURE.

Your parser might not support instantiating arbitrary objects, but those your programs interact with might... :(

Anyone else recall the problems with YAML vulnerabilities? An old blog post by me: [http://williamedwardscoder.tumblr.com/post/43394068341/rubys...](http://williamedwardscoder.tumblr.com/post/43394068341/rubys- principle-of-too-much-power)

So never ever use YAML for tainted input.

</comment><comment><USER20> One problem I've hit a few times is parsing of strings with escapes in YAML. In JSON it's absolutely clear how escaping is works, in YAML, in practice, different parsers do subtly different things.

<comment><USER21> I have had a similar experience with spaces handling in yaml: the application configuration was producing error because of tabs were being used instead of spaces ....

</comment></comment><comment> chris-at Shameless plug: Human JSON, [http://hjson.org](http://hjson.org)

A different approach to using JSON for configuration files. It sits between JSON and YAML.

<comment><USER22> I like the idea. I like that you even round-trip comments. I suppose that doesn't add too much complexity to the implementation?

Have you ever been bitten by the dwimmy typing of numeric and true/false/null data?

<comment> chris-at No, the whole implementation is actually very simple. It's based on the 'standard' parsers for JS/C#/Python and only differs for handling quoteless stings and the optional syntax.

No problems with dwimmy typing ;) - not saying that it couldn't happen but I think that would be the exception. Not having to use quotes/escape characters helps a lot more.

</comment></comment></comment><comment><USER23> I hadn't really looked into YAML before, so I fed it some data for a web app I'm working on.

Man, It sure is condensed, but because of that, not very readable to me. If this is the standard for YAML, it's definitely interesting, but not my cup of tea. It's sometimes hard to parse where a list ends or an object begins. If you want to argue that it's more space efficient, I'd say, just use gzipped JSON. If you want to say you're using it for the spacing and/or line breaks, I'd just say find a viewer that prettifies your JSON well.

Having a delimiter, at least when you're representing chunks of data, is really useful, easier to code for, and easier to read than tabs or other systems. This, not so much. It's kind of a hot mess. Maybe that thinking works well in python, but I'm not so sure the principle translates away from code. If I have a list of objects, I really need to know where one thing ends and the next begins without having to keep track of more than one thing at a time.

<comment><USER24> Your argument is inconsistent. You're saying that YAML is hard to read, but you suggest people who find JSON hard to read ought to use a viewer that prettifies it. Why aren't you applying your own logic to YAML, and finding a viewer that makes it easier for you to read?

<comment><USER23> YAML requires a specific indentation and spacing to work. There's no changing the layout.

JSON is free to do whatever. You could have everything in one line if you wanted. You could use indentations of 8 spaces or 21 tabs. White space does not matter! Point is, it is not hard to figure out a sensible indentation and line breaking scheme if you need it. This is the beauty of braces when dealing with data.

</comment></comment></comment><comment><USER25> Yaml is in fact a superset of JSON. You can parse a json with yaml parser. You can also mix json and yaml in the same document and use [..., ..] for annotating arrays and { "bar" : "foo"} for objects. Some yaml libraries allow you to generate yaml that has one style for top level and json style for nested elements / long arrays to improve readability.

However I have also learned the following:

\- in python, parsing yaml file is hundred times slower than json (in fact, my benchmark was showing around 400x slowdown). Therefore you can't really use it in cases where performance matters at least a little bit. A yaml 1k line yaml can load more than half a second (yrmv)

\- if your yaml doc is longer than two screens, it loses its readability benefits.

Therefore it is best to use a whole directory of yaml files, each describing a specific feature. E.g. Ansible is a good example of how to use yaml files.

<comment><USER18> > Ansible and YAML

I am searching for an replacement of / alternative to Ansible written in Go or Rust that uses JSON or INI as config format.

(Ansible is written in Python. Both Python and YAML rely on outline indentation which causes many headaches)

</comment></comment><comment><USER26> He should compare the specs too. I can learn JSON in less than 2 minutes. I cannot say the same about YAML.

<comment><USER27> And it might just be confirmation bias, but I've seen far more exploits in YAML parsers than in JSON parsers. YAML might be okay for configuration files, but I would never use it for data exchange…

</comment></comment><comment><USER28> YAML = configuration, JSON = serialization.

<comment><USER29> I wish they'd called it YACL instead. At least JSON is an accurate acronym!

</comment></comment><comment><USER30> Hmm, I don't like the fact that strings don't have quotes; 1 vs '1', false vs 'false', with javascript's === operator, it's nice to be explicit about the type of data, since javascript is where most json (and later YAML maybe?) gets consumed...

</comment><comment><USER31> YAML seems inherently unsafe as it's indentation based, which makes copy- pasting from different levels very difficult. The best (and one of the oldest) serialization format is S-expressions. You have the best of both worlds, compactness and non-significant whitespace.

</comment><comment><USER32> Comments, trailing commas, and 64-bit integers. That's all I want. Is that really so much? :(

</comment><comment><USER33> I really like yaml. Especially for writing config files. But I still wish there was a cut down version without the bells and whistles that aren't really useful/relevant to human read/written documents. Just a superset of json syntax, not semantics.

<comment><USER34> [https://metacpan.org/pod/distribution/JSONY/lib/JSONY.pod](https://metacpan.org/pod/distribution/JSONY/lib/JSONY.pod)

</comment></comment><comment><USER35> I've heard of YAML, it seems ok, but it'll never catch on. JSON is too established.

</comment><comment><USER36> I got my own small language too: [https://github.com/Cirru/cirru- json](https://github.com/Cirru/cirru-json)

</comment><comment><USER37> I'm suprised nobody mentioned that JSON lacks date data type.

This is annoying as not everybody using ISO 8601 strings as dates.

<comment><USER38> As several comments here point out, the intended usage of JSON is as a serialization format. In which case, I would expect dates to be in epoch time (if you need to include timezone data, that should be a seperate field).

What annoys me is that JSON lacks a binary data type. The best you can do is base64, which really sucks if 99% of your binary data falls into the ascii range, but you have the occasional high bit character and you explicitly aren't trying to treat it as unicode.

<comment><USER37> "I would expect ..." that's the problem. Expectations fail when both sides don't have the same expectations. As there is no way in JSON to specify what type a field is and as dates aren't even specified in the JSON, you aren't sure if dates are in epoch time or any common or uncommon variant of ISO 8601 (or worse, non of these two options).

JSON hasn't been designed for binary data, so it's not surprising that it lacks a binary data type. There are several options besides base64, you could e.g. use yEnc or BSON.

But unless you have really large binary data (in that case I would instead of embed it in JSON, only embed an URL in JSON and let the client download the data separately), I wouldn't bother with another encoding than base64. It is easily compressable and this is handled transparently, so you reach such a low overhead that it is hard to justify using a non-standard option like yEnc.

</comment></comment></comment><comment><USER39> Is compression rate nowadays still a factor? If so, is the performance of YAML worse than JSON?

</comment><comment><AUTHOR> wow, there are some really amazing points here. the take away i've gathered is that yaml is preferred for configuration, with json being the clear winner for data interchange. any suggestions for improvements to the site or content?

</comment><comment><USER40> I'd already be pretty happy if we moved from XML to JSON. YAML would be icing.

<comment><USER41> JSON is the new XML.

<comment><USER18> Yes, BUT. The other day someone proposed a JSON 'standard' that mimicked SOAP - don't do that.

JSON is beloved because it's easy and simply. XML was originally simple too with just DTD as Schema. Then they come up with XML-RPC, XMLSchema, XSLT, SOAP and many other complex concepts that in the end more or less failed.

<comment><USER9> > XML was originally simple too with just DTD as Schema.

The complexity of XML has not changed since its inception.

> Then they come up with XML-RPC, XMLSchema, XSLT, SOAP and many other complex > concepts that in the end more or less failed.

This doesn't really has any bearing on the specification of XML itself. XML is simple (with some caveats like entity expansion), and extremely flexible. The problem is that it is designed to be read and written by machines, while still being debugable by people. It is extremely verbose. It shines in some use cases, eg for documents with a complex structure and a lot of semantic metadata. But it is even less suitable than JSON for configuration files, for instance.

<comment><USER13> the problems with xml (as in "outside the XML-RPC, XMLSchema, XSLT, SOAP stuff") IMHO arises these two / three points

* it's a little too verbose (<xml></xml>.. while even S-expressions use just ')' as terminator)

* there is no obvious way to transform any xml to an object (pojo is the best aproxymation, but how do you differentiate between a sub-tag, a text node, and an attribute?)

* it's essentially typeless (how do you serialize a number? how to differentiate it from a string? from a boolean?)

<comment><USER9> I agree that it is verbose, but I am not convinced that S-expressions are the solution. In a complex, deeply nested XML document, you should be able to tell where a given tag is inserted without counting parentheses.

> there is no obvious way to transform any xml to an object (pojo is the best > aproxymation, but how do you differentiate between a sub-tag, a text node, > and an attribute?)

That's OK. Just don't use XML to serialize data structures. IMHO, the use cases at which it is good are a lot closer to use cases for which HTML works than when you hesitate between XML and JSON.

> it's essentially typeless (how do you serialize a number? how to > differentiate it from a string? from a boolean?)

That's not entirely wrong, but you can enforce a lot of things via XML schemas (eg, something like XSD or RelaxNG).

<comment><USER41> > _you can enforce a lot of things via XML schemas (eg, something like XSD or > RelaxNG)._

XML is structured text that can be validated. XML's biggest selling point!

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I wished the author would have _not_ used flash for the buttons.

<comment><AUTHOR> there was difficulty getting the copy feature to work outside of flash. did you run into a specific issue?

<comment><USER21> Nothing too specific, but I usually have flash disabled on the browser I use the most and had to view the website in a basic Chrome install instead (which I do have installed for this kind of cases). ;)

I thought, honestly, that html5 api was able to provide the same capability as flash, as far as file/clipboard was concerned.

<comment><AUTHOR> thanks, i'll investigate</comment></comment></comment></comment>


9 Women Can't Make a Baby in a Month - <AUTHOR> http://www.bothsidesofthetable.com/2011/03/30/9-women-cant-make-a-baby-in-a-month/

<comment><USER2> Originally posted in TechCrunch, which was submitted here:

<http://news.ycombinator.com/item?id=2387766>

Many comments there already.</comment>


Ask HN: What's your favourite typeface? - <AUTHOR> <comment><USER2> Adobe Garamond [0] is really nice to look at, I think, especially for long passages of text.

With Akzidenz-Grotesk [1] as a runner-up (and for headlines etc.). Font fun fact: This was actually the font Massimo Vignelli originally used on the NYC subway system, before the MTA changed it to Helvetica (which is a fine choice, too, though I personally think Akzidenz (on which Helvetica is partly based) is prettier) [2].

[0]: [https://en.wikipedia.org/wiki/Garamond#Adobe_Garamond](https://en.wikipedia.org/wiki/Garamond#Adobe_Garamond)

[1]: [https://en.wikipedia.org/wiki/Akzidenz- Grotesk](https://en.wikipedia.org/wiki/Akzidenz-Grotesk)

[2]: [http://www.helveticasubway.com](http://www.helveticasubway.com)

</comment><comment> J-dawg Fun typeface fact: Stanley Kubrick's favourite was Futura Extra Bold, it was used on the posters for Eyes Wide Shut and 2001

Source: ([http://www.theguardian.com/film/2004/mar/27/features.weekend](http://www.theguardian.com/film/2004/mar/27/features.weekend))

The Nike logo is also from the Futura family ([https://www.quora.com/What- font-is-used-for-the-Nike-logo](https://www.quora.com/What-font-is-used-for- the-Nike-logo))

<comment><USER3> Other typeface fact! The title text in 2001 uses capital O's instead of zeroes. [1] The zeroes in Gill Sans are thinner than the O's, so part of me thinks Kubrick wanted the logo to look more futuristic.

[1] [https://i.ytimg.com/vi/e-QFj59PON4/maxresdefault.jpg](https://i.ytimg.com/vi/e-QFj59PON4/maxresdefault.jpg)

</comment></comment><comment><USER4> Chicago.

For fun, for nostalgia, for distinctiveness, for boldness, for my heart and my soul.

[https://en.wikipedia.org/wiki/Chicago_%28typeface%29](https://en.wikipedia.org/wiki/Chicago_%28typeface%29)

Susan Kare, its prolific designer:

[https://en.wikipedia.org/wiki/Susan_Kare](https://en.wikipedia.org/wiki/Susan_Kare)

</comment><comment><USER5> Neue Haas Grotesk [0], the original name and style of Helvetica.

[0] [http://www.fontbureau.com/nhg/](http://www.fontbureau.com/nhg/)

</comment><comment><USER6> Anything I don't need to extra pay for!

Lato is nice - it's on Google Fonts.

</comment><comment><USER7> I enjoy using "Duru Sans" whenever I need to write some paragraphs.

For headings and titles I like a clean "DejaVu Sans"

</comment><comment><USER8> Gotham by Tobias Frere-Jones. A very similar open source alternative is Montserrat by Julieta Ulanovsky

</comment><comment><USER9> Is there such a thing? Sounds a bit like 'favourite colour'.

Anyway, that said, Fira Sans is very nice.

</comment><comment><USER10> Chaparral.

</comment><comment><USER11> Bembo. Impractical as it may be sometimes, I just adore the capital R.

</comment><comment><USER12> I just enjoy writing code using "Monospace".

</comment><comment><USER13> Depends on why I am selecting a typeface.

</comment><comment><USER14> Open Sans

</comment><comment><USER15> consolas 11pt

</comment><comment><USER16> I'm a huge fan of Freight Text Pro for serifs ([https://typekit.com/fonts/freight-text- pro](https://typekit.com/fonts/freight-text-pro)). It's like... just rounded enough to be soft and kind, but still be professional. I'm talking mostly about the medium weight, but the whole series is nice.</comment>


How many times are we going to "kill" Java? - <AUTHOR> http://www.jroller.com/aalmiray/entry/how_many_times_are_we

<comment><USER2> Till it's dead.</comment>


The solution to nearly everything: working less - <AUTHOR> http://www.theguardian.com/commentisfree/2016/apr/18/solution-everything-working-less-work-pressure <comment><USER2> The work that matters is not busywork, but putting into motion ideas that really change things. That can take some hard work, but it is critical to avoid confounding relevance with busyness. What we need is less bullshit work and that means not valuing people only by their labor. The real solution is building an equitable society. As long as people are what they can work for they will work as much as they possibly can.</comment>


Painful Lessons - The story of Dan Ariely (of Predictably Irrational) [pdf] - <AUTHOR> http://www.predictablyirrational.com/pdfs/mypain.pdf <comment><USER2> I read Predictably Irrational last year, and as an ER nurse, I think quite a bit about one of the lines from his book.

<from memory> Dan wrote that he presented some research he had done to his former nurses on how removing bandages slower would cause less pain for the patients. To which, one of the nurses replied, "but removing the dressings quickly hurts the nurses less".</>

One of the hardest things to get over in the medical/nursing profession is willingly causing someone pain. Some people deal with it by being control freaks and complete ass hats. Others manage somewhat better.</comment>


Economic Analysis of Medicare for All - <AUTHOR> https://www.peri.umass.edu/publication/item/1127-economic-analysis-of-medicare-for-all <comment><USER2> One thing that sometimes gets lost in the "health care is inefficient" discussion is that one person's inefficiency is another person's living. The cost controls the paper appears to advocate for literally mean someone is making less money, that someone will advocate strongly against it. I've spent the past 3.5 years in healthcare, everyone is convinced they're not the problem, that they're underpaid or overworked or whatever. I would love for some sort of centralized system to push down costs, but I fear it's not realistically every going to happen.

<comment><USER3> > that they're underpaid or overworked or whatever

Having family in healthcare and being a lifelong patient due to a congenital defect, a job in software (including management obv) is a breeze compared to health care worker jobs across the board. They require more "schooling" (via mind-numbing training), are underpaid, have much more serious consequences from mistakes, have less oversight, work longer hours and under worse conditions. It's disheartening.

<comment><USER4> People's work shouldn't be reduced, but drugs and devices should be to an extent. Firefighters told the portable EKG costed thousands of dollars (5 or 10 don't recall). That thing had bad 2G connectivity so the graph coudn't be sent to a cardiologist. The sensor/dsp part is worth money, the rest would cost 100$ from any smartphone maker today with better performance and portability.

I'm sure the price is rigged for margins. This shouldn't be a market, it should be an open duty to make these cost efficient.

<comment><USER5> The real cost is not so much in the hardware but in the certification requirements. Medical devices need to be built to and work at a higher standard than consumer electronics, for obvious reasons.

<comment><USER6> But if the cost becomes so high that people simply go without the devices, is that really a good tradeoff? Maybe a device with 1 in 10,000 failures is better than no device at all, for some subset of illnesses?

Also, I suspect this is FUD by some entrenched medical devices companies who know how to play the game of complying with standards. Anyone here ever gone through compliance testing with software? I've seen systems pass that are worse than what I would have just thought up in 30 minutes and coded up for fun. It's just a warm fuzzy feeling.

<comment><USER7> That's one thing. But there's other problems:

1) certification that takes 10 years (more like 3, but ...) means you, at the very best, have 10 year old technology

2) Certified at a higher level. That can for various reasons be very different from reliable at a different level. For instance, circumstances change or knowledge advances.

For instance certification tends to take "proof" that something works. Yet the most reliable robots are pretty bad hardware, with the ability for multiple components to do the same job "most" of the time. Such a device, despite being much more reliable, is disqualified a priori in nearly all certification processes I've seen.

(needless to say, every time the things they take as proof tend to be ... less than proof)

Plus we've all been in a company having this discussion. "For the price of this one 'reliable' server we could have 20 normal ones, and they would be a hell of a lot more reliable together. Hell, just give me 3 of the cheap ones and I'll make it more reliable". And we all know what the boss's answer and the resulting reliability was.

3) You assume no regulatory capture (or outright dishonesty on the part of government employees and/or lawmakers)

</comment></comment></comment></comment></comment></comment><comment><USER8> Hypothetical economic studies and analyses are almost worthless. In normal science, you need something to be testable, verifiable, and reproducible. I'm quite sure none of these are possible.

Just as a counterpoint, the US public primary school education is state run and funded, and has both poor outcomes and is the most expensive in the world [1]. Just because something is run or controlled by the state does not mean it will magically be either efficient or high quality.

[1] [https://www.theguardian.com/us-news/2018/sep/07/us- education...](https://www.theguardian.com/us-news/2018/sep/07/us-education- spending-finland-south-korea)

<comment><USER9> Quick question:

What if America's education problem is that the children don't have parents who can nurture them?

Because we have stagnant or decreasing real wages? Because the cost of daycare, housing, health, and advanced education have all gone up? Because we're making it harder to declare bankruptcy? Because we're criminalizing activities, and ripping families apart?

Maybe it shouldn't be a surprise that our education is ranked poorly.

And _pointing to_ education, as though it's a system we can study in isolation, and claim that it's a failure, therefore other state-run systems must also be failures, isn't really being honest?

And maybe it's worthwhile to look at other countries with the economic conditions we're proposing. Like single payer healthcare. Because we can look at them.

You're absolutely right that "just because something is run or controlled by the state does not mean it will magically be either efficient or high quality."

But people like you seem to _delight_ in using that as an argument against government programs that have been shown to be effective, again and again, in country after country.

So then I can say, "just because something is run or controlled by the state does not mean it will be either inefficient or low quality."

And we've both said something completely meaningless, and now can we please get back to looking at examples from other countries, and try to learn from them?

<comment><USER10> US education is top notch based on international PISA scores if you break it down by race and compare them to europe, latin america, africa, etc

[https://nces.ed.gov/surveys/pisa/pisa2015/pisa2015highlights...](https://nces.ed.gov/surveys/pisa/pisa2015/pisa2015highlights_3f.asp)

Singapore almost always takes 1st in international test scores and their long time leader didn't pull punches

[https://imgur.com/a/a8nCQUO](https://imgur.com/a/a8nCQUO)

and it's not an income thing, the poorest whites and asians score as high as black students from families making 200k+ a year

[https://i.imgur.com/PD9hz9b.jpg](https://i.imgur.com/PD9hz9b.jpg)

So in a way you're right, US government does run their education system very well, it just seems to be a racial thing which can never be spoken about politically so it's just ignored as the elephant in the room

<comment><USER9> Since people were treated separately based on their race (slavery, no right to vote, no civil rights, redlining, segregated schools), it's not a surprise you can still measure the impacts of that decades later, based on race.

It takes a long time to undo damage like that.

</comment></comment></comment></comment><comment><USER11> A lot of issues with America's healthcare system boil down to what I call "the interception problem". A quarterback who throws an interception directly to a defender without a wide receiver in the vicinity is treated the same as someone who hit a receivers hands and was tipped to a defender when you are looking at the stat sheet. Your perception of the analysis changes drastically if you actually observe the actions going on.

I'll take an example from the real world to illustrate my point. When you look at the data, the United States clearly has the highest infant mortality rate of developed countries. On its face it would seem that the United States is clearly failing pregnant women, and that this is a terrible problem that needs to be addressed. However, if you observe the differences between the data sets and actually view how deliveries happen in real life you see a different picture.

Not all pregnancies carry the same risk, and the US has a higher percentage of high risk pregnancies than other countries. If you compare people in the same cohorts the US fares a lot better. In layman's terms, we shouldn't treat an infant death from a 25 year old mother who carried to term the same as one from a 40 year old born a month premature. The US is also the most aggressive country in the world when it comes to attempting to save prematurely born children. We try and succeed at a higher rate than anywhere else in the world. I have failed to meet a person who thinks trying to save a prematurely born child is a bad thing. Yet it's those kind of actions that skew the stats.

We need more advanced medical statistics. I hope the sabermetrics revolution makes its way into the medical field. If more people are interested, I could probably expand my thoughts further with other examples that look bad on the surface, but actually aren't as bad as you think.

</comment><comment><USER12> It seems to me that industrialized countries the world round have different ways of organizing the relationship between patients, payers and providers. There's nearly 100% public models like the NHS in the UK and hybrid market systems like those in Singapore and Switzerland.

But the one thing they all seem to do the same is how they keep costs down. They give the payer, whether that's the government or separate insurers a legal framework for setting prices.

I know correlation is not causation but until some country shows strong price performance while implementing a different scheme it seems wise to defer to the one that is ubiquitous.

<comment><USER5> Price controls cause shortages. Simple economics.

<comment><USER13> there is always a simple economic reply to every proposal —- neat, plausible, and wrong

</comment></comment></comment><comment><USER14> My biggest fear of a bill like this is even should we have the most progressive anti corruption government implement this law originally, whats to prevent this from becoming incredibly wasteful just like our military is. I.e. we spend a trillion dollars over decades trying to develop some drug that turns out to take us nowhere, while enriching pfizer shareholders this time instead of lockheed martin ones.

I absolutely support medicare for all, even though as a healthy young software engineer this will raise the cost of my healthcare a ton, I'm just nervous that this will result in the largest negative iron triangle in the history of our country.

<comment><USER15> This is why the scope of government matters.

I do not understand why people have this idea that it's the job of the government to do things like speculate on the economy via quantitative easing, or save money overall on healthcare costs. The federal government ought to have a few simple jobs --- the ones laid out in the constitution, and everything else can be left up to the people and to the states.

I would rather live in a country where healthcare maybe costs more than it otherwise could, and where the economy maybe recovers slower than it otherwise would have, than to live in a country where the government takes lots of our money trying to fulfill promises that it cannot keep.

Medicare is projected to be insolvent in 2026, and Social Security is projected to be insolvent 8 years later. We're due for an economic downswing in the next few years (if not the next few months). Our economy will not keep up with the developing world powers; NATO is increasingly irrelevant and the petrodollar is threatened.

What are we going to tell the people who depend on these dying programs? "I know that you worked your whole life in a factory, and I know that you are too old to work, and I know that you paid into this system your entire career, and I know you aren't getting enough to get by. But we had the best intentions in mind!"

America is rich because we won WWII, not because of American Exceptionalism. The comfortable life that American culture was built on (while the rest of the world needed half a century to recover) is going away quickly. The social programs that we _already_ have in place have less than 6,000 days remaining before they fall apart, and in these last hours, we're seriously talking about adding on?

No thanks. I'm okay with living in a poor country. I'd prefer for my government to not fail as a result, though.

<comment><USER16> Medicare and social security won't be insolvent. They can go on for a long time by doing some adjustments that account for life expectancy and other factors. Unfortunately the people in DC are more interested in fighting each other than running the country in a responsible manner.

</comment></comment></comment><comment><USER17> Its such a fundamental change I doubt a study could accurately predict changes. I can't read the PDF but I know debate often misses things like: * A big boost for companies as unprofitable companies don't have to pay healthcare of employees. (assuming paid with taxes) * Free medical care means things like ambulance chasing lawyers are not required * Govt is more incentivized to look after the health of citizens as it has to pay for diabetes treatment etc. * People are more likely to retire early, or quit work and live cheaply.

</comment><comment><USER18> For an in depth look at the state of the current US system as compared to other developed countries see this report:

[https://www.mckinsey.com/~/media/McKinsey/Industries/Healthc...](https://www.mckinsey.com/~/media/McKinsey/Industries/Healthcare%20Systems%20and%20Services/Our%20Insights/Accounting%20for%20the%20cost%20of%20US%20health%20care/MGI_Accounting_for_cost_of_US_health_care_full_report.ashx)

</comment><comment><USER19> The only thing America can really do to get healthcare costs under control is actually really obvious: put down the fork.

<comment><USER20> What about the herion addicts that the healthcare system created? I don't think less food is going to solve their problems.

</comment></comment><comment><USER21> The math here is based on the idea that MFA would reduce the per-person expenditures by 19% (19.2% actually)

(1) 5.9% by unilaterally reducing drug prices by 40% (2) 2.8% by unilaterally reducing medical service prices by 20% (3) 1.5% through the claim that MFA would have fewer "excess services" (4) 9.0% from allegedly increased efficiency due to only having to deal with one payer

Is this at all plausible?

Achieving (1) and (2) would be - um - difficult, to say the least! In real life, prices would be set by a political process. Our actual history of attempts to unilaterally reduce medical reimbursement reates is not promising! [see [https://en.wikipedia.org/wiki/Medicare_Sustainable_Growth_Ra...](https://en.wikipedia.org/wiki/Medicare_Sustainable_Growth_Rate) or the debate over Medicare drug price negotiation].

(1) & (2) con't: Imposing a single-payer system and then having that payer set prices is effectively the same as imposing a national price control regime, which we in theory could do without MFA. We have not done this, despite the fact that it would save everyone an enormous amount of money. Why not? Because it would be insanely controversial and take a ton of money out of some people's pockets, especially doctors and nurses. Will this be easier under MFA?

(3) The idea that MFA would be structurally less likely to provide "excess" health services seems pretty optimistic indeed. Our military, for example, is not really known for being budget conscious and aggressively efficiency minded. Nor are our state and local level agencies, e.g. the MTA here in NY. Spending policies are set by a political process, and political processes are prone to over- rather than under- spending in every case I can think of.

(4) The 9%(!) savings from "billing efficiencies" is based on an assumption that billing expenses in medical offices will be reduced by 2/3 when there is only a single payer. Why would this be? Billing expenses scale with the number of bills, not the number of vendors. Will MFA lead to fewer procedures on net? Will it eliminate the concept of prior authorizations, which represent the bulk of these "excess" BIR expenses? Will providers and patients not have coverage disputes? Will MFA have dramatically superior automation than private payers? Note that Germany has a multi-payer system and has Canada-like administrative costs [[https://www.healthaffairs.org/doi/full/10.1377/hlthaff.2013....](https://www.healthaffairs.org/doi/full/10.1377/hlthaff.2013.1327)]. There are hidden variables here.

Here's the thing:

The most superficial argument in favor of MFA is to look at a country like Canada and say "Canada spends X / pp on healthcare and they have a single payer system, therefore if the US adopts a single payer system, our costs will drop to X!". That's not real analysis, and it ignores all the cost drivers that have nothing to do with the payer. This paper is a drill-down to component costs, but ultimately is no less superficial. MFA billing will be 65% more efficient because Australia billing is 65% more efficient than the US. Prescription drugs will be 40% cheaper because Canada pays 40% less than the US. And so on.

If you could realize any of these cost savings in MFA, you could realize them now. But you probably can't - not easily, anyway, and after burning all your political capital on a $1T/year tax hike it will only be harder. The cost- savings will be compromised to get the medical industry on board, just like it was during the Obamacare debate. And now you can toss this whole analysis in the garbage.

This is wish-casting dressed up in 200 pages of rigorous-looking analysis, designed to get people to read the abstract, then look at the page count, and then treat it as credible.

MFA is not going to save the system money. Take it to the bank.

</comment><comment> time-domain0 Let's say an American has to have a very expensive treatment for stage IV cancer that exceeds their insurance's lifetime limit and they can't work. They can say goodbye to their health insurance, goodbye to their savings and hello to bill collectors will force them into bankruptcy where they have to justify keeping a home, a vehicle and the clothes on their back. Dying and having to pay late fees that a person can't pay. It's criminal.

It really sucks when that person is married with children. It's often better for the spouse to divorce them and take all the assets well ahead of declaring bankruptcy so they can't be liquidated and lose everything.

This is what corporate hospitals, for-profit insurance companies and big pharma has reduced care to: make as much money as possible while screwing over patients, and killing them with substandard care compared to the rest of established economies. Unregulated capitalism is a cannibal.

</comment><comment><USER22> How can they assume this will not change how everything else works?

Yes. You can say statistically we did the comparison by holding everything else the same, but it only means "statistically". It definitely does not mean in reality you can hold everything else the same. There is no way when the policy changes, the system still works as before. This kind of study is totally delusional.

A policy works in other countries does not guarantee it will work in the U.S. For one thing, U.S. doctors make much more money than other countries. There are also other many differences. How can you assume you can simply move a policy successfully from other countries without making other important changes?

<comment><USER23> Second order effects... the bane of well-meaning policies.

On the other hand, how else are you going to do it? Do you know what the second-order effects are going to be? How sure are you? Can you prove it to someone who doesn't hold the same intellectual framework or political leaning that you do?

</comment></comment><comment><USER24> | Medicare for All could reduce total health care spending in the U.S. by nearly 10 percent, to $2.93 trillion, while creating stable access to good care for all U.S. residents.

how? by taxing a few earners to pay for everyone else not earning. is that fair? in that light, a ten percent reduction in cost is meaningless.

<comment><USER25> Uhh, you're aware hospitals don't turn people away who are injured and often end up with a lot owed to them they just can't recover right?

Also if everyone has healthcare they'll get treated earlier before a condition blows up and... they get stuck at the ER getting a bill they'll never be able to repay.

Our US healthcare system just sucks compared to other countries UNLESS you are well off.

I wouldn't short change arguments saying covering everyone is actually less expensive.

<comment><USER19> Look up 5-year cancer survival rates by country. That metric at least attempts to measure the performance of the healthcare system. The studies that say our healthcare system "sucks" are looking at overall health of each country's population, not the performance of their systems.

To condemn the healthcare system based on the overall health of a nation that spends all day watching TV and shoving cheeseburgers in its face is absurdly disingenuous.

<comment><USER25> I'd say the system sucks when a valid reason to exclude someone form an organ transplant is "don't have 10k in savings to cover rejection meds".

Without Medicare for all it's a pay to win system where the cost of life saving treatments are literally beyond what most people could ever reasonably make.</comment></comment></comment></comment>


Picasso's Top 7 Tips for Creating an Exciting Life - <AUTHOR> http://www.positivityblog.com/index.php/2008/04/04/picassos-top-7-tips-for-creating-an-exciting-life/ <comment><USER2> Einstein's Top 3 Tips for Digg Bait

1) Write something with which everyone agrees and attribute to some famous figure.

2) Condense writing into a numbered list.

3) http /submit => printf("%s's Top %d Tips for %s", celebrity, num, Something_Everyone_Wants)

<comment><USER3> Ie, give people what they want in an easily digested form.

<comment><USER4> This sort of thing is a bit more sneaky than that.

</comment></comment></comment><comment><USER5> Nice of author to write this piece, but really no need to expand upon the words of the master. They stand on their own. 1,494 words reduced to 106:

"He can who thinks he can, and he can't who thinks he can't. This is an inexorable, indisputable law."

"I am always doing that which I cannot do, in order that I may learn how to do it."

"Inspiration exists, but it has to find us working."

"Only put off until tomorrow what you are willing to die having left undone."

"Action is the foundational key to all success."

"Others have seen what is and asked why. I have seen what could be and asked why not."

"If only we could pull out our brain and use only our eyes."

"Youth has no age."

<comment><USER6> But people would not accept a blog post made entirely of quotes, even ones that much deserve quotation. You have to say _something_ , or you're just stealing someone else's act.

</comment></comment><comment><USER7> Number 8: Stop spending the few fleeting moments you have before you depart your increasingly pathetic and desperate life looking for tips about motivation on the internet and dedicate that time to either reading about the things that make your heart beat faster when you talk about them or self teaching something boring you need to get through to learn the fun stuff.

<comment><USER4> Admittedly this is a lame essay. But not all essays about what to do are a waste of time; I've learnt from a few. And certainly it doesn't matter whether they're "on the internet." Practically everything is, now.</comment></comment>


Ask HN: Is Ethereum the next Bitcoin? - <AUTHOR> It's surging right now but seems to be heavily underreported.  They're pretty similar, though, right?  Why is it climbing at all? <comment><USER2> Heavily underreported? Yes.

Similar? Yes.

Ethereum is different because it is built to be a platform first and foremost. This platform is for allowing other individuals and organizations to build new blockchain technology without having to engineer their own blockchain.

Imagine if every crypto company had their own blockchain, adoption of crypto would be unlikely.

So, Ethereum allows you to create 'smart contracts' which you can think of as microservices (yeah, code) that exist forever on the blockchain, maintaining application state on a decentralized and infinitely expanding database i.e. the blockchain.

Industries will be disrupted by the new concept (web3) of the decentralized app or DAPP. This concept effectively removes middlemen from various processes (middlemen charge fees and own your data in a centralized way).

So think:

\- No more centralized trading exchanges with fees.

\- No more Google owning your digital identity data.

\- No more AWS running your computing infrastructure in a proprietary, closed manner.

\- Direct licencing for artists and musicians.

\- Impossible to censor, decentralized news.

The list goes on.

Why is Ethereum different? It aims to make it EASY for others to create ontop of a blockchain.

A few interesting projects:

Golem - Decentralized cloud computing

Uport - Self-Sovereign digital identities

Augur - Prediction market platform

OH and don't forget about the popularization of a new (to me) investment model called the ICO, or "Initial Coin Offering" there are DAPP companies rasing millions of dollars in immediate funding in a matter of days right now.

See Gnosis.

Hope this helps you understand.

Edit: Missed letter (on phone), Formatting

<comment><USER2> ALSO:

A beautiful feature of this market is that most of these projects have whitepapers!

[https://github.com/ethereum/wiki/wiki/White- Paper](https://github.com/ethereum/wiki/wiki/White-Paper)

[https://golem.network/doc/Golemwhitepaper.pdf](https://golem.network/doc/Golemwhitepaper.pdf)

[https://whitepaper.uport.me/uPort_whitepaper_DRAFT20170221.p...](https://whitepaper.uport.me/uPort_whitepaper_DRAFT20170221.pdf)

[https://bravenewcoin.com/assets/Whitepapers/Augur-A- Decentra...](https://bravenewcoin.com/assets/Whitepapers/Augur-A- Decentralized-Open-Source-Platform-for-Prediction-Markets.pdf)

[https://gnosis.pm/resources/default/pdf/gnosis_whitepaper.pd...](https://gnosis.pm/resources/default/pdf/gnosis_whitepaper.pdf)

It's important for everyone to realize that as some of the more technical people in the world, we are uniquely positioned to be able to judge the value of these projects by understanding of the technological implications they introduce.

I.E. We know the value of platforms, well, some of these projects are positioning themselves to be core platforms in an ecosystem where entire industries will be built with software. Any project that makes it easier to build this software is worth looking into and reading their whitepaper.

That's all from me. It's really exciting!</comment></comment>


A light shines on the concentration of power in Silicon Valley - <AUTHOR> https://www.ft.com/content/02b6d334-8c2d-11e8-b18d-0181731a0340 <comment><USER2> Behind pay wall. :-(</comment>


Peltier Application Note – Thermoelectric Cooling [pdf] - <AUTHOR> https://www.cui.com/catalog/resource/peltier-app-note.pdf <comment><AUTHOR> I was nerdsniped by a coworker, who was talking about personal projects. She was working on an wine-rack / cabinet that held a specific temperature. Key to the design is a Peltier module to pump the temperature to the ideal for wine storage.

CUI's application note on Peltier modules was very well written and a joy to read. I've barely touched on the physics of this subject, but it was so clearly written that I was able to understand the overall design process to use this kind of device.

Overall, Peltier modules are far less efficient than classic "compressor" refrigeration units. But Peltier modules are far smaller and far simpler to operate: just apply voltage, and away you go. As such, Peltier modules are the ideal easy-to-use tool for hobbyists, even if its not quite as efficient as what the professional HVAC people use.

<comment><USER2> Just to build on your comment so other hobbyists don't get the wrong idea, Peltier modules are _significantly_ less efficient than compressor-based coolers. To the tune of 30% or more efficiency drop depending on ambient conditions and your heatsink setup. It's also important to note that the overall setup for a Peltier system ends up being a lot bulkier than most people expect when they start. You need a really beefy hot side radiator and fan to get any significant cooling potential out of the system - think large CPU heatsink + fan size and you're close. If it's humid you'll also have to deal with condensation on the cold side so you don't accidentally get water dripping on your electronics.

<comment><USER3> I agree. Peltier fits a narrow niche. If you want a small temperature drop and can dissipate the heat on the hot side and are okay with the inefficiency it's for you. I tried to create a Peltier cooling system for a wearable device. It was a miserable failure. WIthout a way to dissipate the heat (your CPU heatsink + fan comment) it resulted in a net heat gain.

<comment><USER4> Forgetting about the enormous heat sink is a typical rookie mistake. Those things produce lots of heat when you try to cool something. They are much better suited for heating something to a specific temperature than cooling.

<comment><USER5> Would an aerogel-like material suffice as an 'enormous heat sink'? Has anyone tried this?

Edit: would a metal aerogel not count? (Definitely not maker ready though, I assume)

[http://www.aerogel.org/?p=932](http://www.aerogel.org/?p=932)

<comment><USER6> A metal aerogel would have very high surface area (much like adsorption humidity control crystals) but that's not really helpful when you then need to move the fluid touching all that surface area in order to remove the heat.

Typically the fluid will be air which sucks at moving heat (hence why aerogels are great insulators as they hold a lot of air).

I'm not positive but I suspect that an aerogel in a higher specific heat fluid wouldn't do any better as the flow volume through the aerogel would be quite low bounded by the volume of the aerogel.

If you want to cool the hotside of a TEC you need to push a lot of watts per unit area. The best things for that are high specific heat fluids which are often used in compressor systems and then they're termed refrigerants so you're back to traditional air conditioning. The other option is very cold fluids (liquid nitrogen) but at that point you may be better off bringing the LN2 into more direct contact with whatever you're trying to cool.

</comment></comment></comment></comment></comment></comment><comment><USER7> I've been working on solar powered Peltier AC for my home. This past summer it was able to keep my living room (250sqft) at a comfortable 72F - 75F even when the outside temp was over 95F. It is crazy power hungry, using 12v 5A, but with solar its fine. The hard part as people have said is the heat dissipation and dealing with high ambient temperatures.

My newest design incorporates a few new upgrades. 1) geothermal cooling to dissipate the heat. As the ground temperature stays consistent at ~65F. Allowing me to not worry about the ambient temperature anymore 2) I moved to a 24V 6amp peltier which has a larger delta from the hot to cold side. 3) I now use a 24v ~7.6amp solar panel to power it. 4) I added a 15 Amp high-power motor driver so I can switch between producing cold and hot air. So now it will be viable in all weather conditions.

A core idea is to keep costs cheap which is why I have not added a battery to the mix. Although it would be nice as some nights are quite hot. I got the 24v panel used at $50 and the peltiers are super cheap (3 for ~15). The motor- controller/h-bridge was ~$40, but I didn't want to cheap out on that though and start a fire.

Its quiet unless I turn the fans up and doesn't cost anything to run after initial setup costs, due to the solar. My future plans for making it even better are to use multi-stage peltiers and try to leverage the hot side to produce more power. Also to add raspberry pi so I can control it remotely.

<comment><USER8> How do you use geothermal? Do you have a diagram or picture of your setup? I would love to build something like this

<comment><USER7> I use geothermal as a way to absorb/dissipate the heat. I got the idea from here: [https://forums.overclockers.com.au/threads/concrete-slab- wat...](https://forums.overclockers.com.au/threads/concrete-slab-water-cooler- loop-hooked-up.800958/) Instead though I dug a trench outside that was 4ft deep 20ft long and then buried some pex pipe. As the water flows into the aluminum block attached to the peltier it absorbs the heat and then as it enters the ground it dissipates so when it comes out of the ground of its back at 55F. The water is moved with a 12v pump. The longer the run the better as the ground is not efficient in energy transfer. If its to short it wont cool down all the way.

I thought of trying to use copper pipe with round engine heat sinks attached to it, to increase the energy transfer rate. However it didn't seem like the copper would last long before potentially reacting with the ground.

Simple diagram: [https://www.ernstheating.com/wp- content/uploads/2018/01/Erns...](https://www.ernstheating.com/wp- content/uploads/2018/01/Ernst-geothermal-heating-768x768.jpg)

<comment><USER8> Thanks a lot. I agree copper will probably not last long but maybe some HDPE flexible pipe would work.

</comment></comment></comment></comment><comment><USER9> Peltiers are a fascinating piece of tech, I remembering hacking together a cooling system for a high school project (20 years ago now..) to show people and have had a fascination ever since. Problem is they just aren't that useful due to their large inefficiencies. Situations where power consumption, heat removal and humidity aren't a problem are pretty rare at any scale. Saying that, if a situation where heat removal is straight forward due to other factors, space is abundant with solar generation (that's not needed/can't be used for anything else) and humidity is benefit, peltiers size and simplicity can be leveraged nicely.

</comment><comment><USER10> Free product idea: Here in NZ, and I suspect other places with lower quality housing, lots of people use electric resistance heaters, and also have problems with damp air and/or dehumidifiers.

How about a solid state dehumidifier+heater using peltlier elements?

A dehumidifier is basically an air/air heat pump, with the cold side optimised for water condensation without freezing, and one issue with them is the noise from the compressor...

</comment><comment><USER11> A neat application with peltiers for CPU cooling: [https://www.youtube.com/watch?v=GZ3SwM2-rD4](https://www.youtube.com/watch?v=GZ3SwM2-rD4)

</comment><comment><USER12> Tech Ingredients: DIY Peltier fridge

[https://www.youtube.com/watch?v=YWUhwmmZa7A](https://www.youtube.com/watch?v=YWUhwmmZa7A)</comment>


Burger King makes an ad about Net Neutrality - <AUTHOR> http://www.adweek.com/creativity/burger-king-deviously-explains-net-neutrality-by-making-people-wait-longer-for-whoppers/ <comment><USER2> This ad only makes it seem ridiculous because of the high prices of the hamburgers. However there are places such as Amazon that charge extra for faster delivery. Net neutrality may be right, but the ad misses the point.

</comment><comment><USER3> [https://news.ycombinator.com/item?id=16226830](https://news.ycombinator.com/item?id=16226830)

</comment><comment><USER4> I'm sure this is staged, but it's a pretty funny comparison nonetheless.</comment>


Shdr – Online GLSL shader editor and validator with live preview - <AUTHOR> http://bkcore.com/blog/3d/shdr-online-glsl-shader-editor-viewer-validator.html

<comment><USER2> This looks cool!

For those interested in tiiiny, efficient shaders, check out shadertoy. It was written by one of the Pixar guys, Inigo Quilez, and has a a lot of awesome user-submitted shaders. [https://www.shadertoy.com](https://www.shadertoy.com)

<comment><USER3> From a quick glance at the title I initially thought it was shadertoy too... and here's a quick reference of how to build scenes with certain 3D objects with this or any other shader tool:

[http://www.iquilezles.org/www/articles/distfunctions/distfun...](http://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm)

<comment><USER4> Would you know anywhere that i could learn about all this glgs malarky, ddg isn't being helpfull...

</comment></comment></comment><comment><USER5> I completely forgot how fun playing with shaders in realtime is. Last time I did this was in AMD RenderMonkey. Look what I made after a 2 minute poking around the editor (it's animated, too!)[1] :)

[1]: [http://i.imgur.com/BGv8dL9.png](http://i.imgur.com/BGv8dL9.png)

</comment><comment><USER6> If you are interested in this kind of tool, you should also conside Tao Presentations. See [http://www.taodyne.com/shop/dev/blog/288-building-a-dali- sty...](http://www.taodyne.com/shop/dev/blog/288-building-a-dali-style-clock) for an example of what you can do with it (in that case, a real-shader-based real-time ray traced clock).

Real-time shader editing, complex scenes built using a real-time 3D document description language, animations, multiscopic 3D movies playback, 2D and 3D text layout, dynamic textures, etc. In short, Tao is a rather complete toolbox for real-time 3D.

</comment><comment><USER7> Quick question; I'm running Linux Mint on a not-very-high-powered laptop (with onboard GPU), trying out this demo in both Firefox (32) and Chromium (37), I find the framerate in Chromium to be significantly better and smoother than in Firefox.

Any idea why this could be? Something about Firefox, or maybe my own configuration? How do I test whether it's actually using hardware acceleration? (or is there no software fallback and I wouldn't see anything in that case?)

Switching to lower polycount objects, even the cube, doesn't do much to improve the framerate either.

<comment><USER8> There are enough factors to make this answer little more than speculation. Please take it with a grain of salt and not as evidence for a course of action.

In theory, the Javascript engine is significantly faster in Chromium than in Firefox[1]. I don't think your system is falling back to CPU rendering (you _would_ notice), but the overhead associated with WebGL is probably higher in Firefox. Additionally, since Chrome runs each tab in its own process, there is perhaps less overhead when switching task context for GL rendering.

[1] According to the April 2013 numbers on [http://arewefastyet.com](http://arewefastyet.com), they're pretty much on par. I can't shake the idea that Google's V8 engine is faster, but I can't prove it, either.

</comment></comment><comment><USER9> Very cool! Some hopefully helpful feedback: Running Safari on a Mac, and the text cursor visually shows up in a different place than the actual editing occurs, making editing tough. It is off by an amount that varies largely when I change the size of the on-screen text, sometimes off by 1 character, sometimes off by 4 characters. At a really large font size, I got it to mostly align and it made editing possible.

</comment><comment><USER10> I've been meaning to do a similar project for a while, but also handling the ability to pass extra data to the shader via texture buffers (it's a useful technique for mass rendering of objects stored within the GPU) although I'm unsure whether WebGL currently supports this as I'm yet to use it.

</comment><comment><USER11> Very cool! A small bone to pick, you should consider raising the contrast on the text in the Share dialog. It's really dark and very difficult to read on crappy monitors.

</comment><comment><USER12> Very nice! Consider adding an option to save a result as a multiline JS string (for inlining in JS code).

</comment><comment><USER13> Looks like the time variable is not updated...

Update: Sorry - Time is just really slow there :D

</comment><comment><USER14> this is really cool project. very interesting.

</comment><comment><USER15> WebGL*

* probably crashes browser</comment>


Ask HN: Small sample size user testing fallacy - <AUTHOR> I had a debate with a colleague of mine about testing some Web UI code.
My friend's argument goes like this: If we cannot test our code with big enough representative sample of Android phones, then let's just release the code and collect usage statistics from real users without user testing it at all.
Basically since testing our code with few phones does not prove that our code will work on 99% of the devices so it is as good as not testing it at all.
I think there must be a logical fallacy in this argument, what is it?
I can think of a counter argument that goes: let's assume we get 99% confidence that our code runs on every phone by testing it with 30 devices:
(1/x)^30 = 1 - 99% then x = 1.166
confidence(N) = 1 - (1/1.166)^N
Now with N = 5, I am already more than 50% confident that the code works on every device. But then the question is where does my assumption of confidence(30) = 99% come from in the first place. <comment><USER2> Depends on the range of Android versions you support and what your app does. I'm not an Android dev but I'm fairly certain if you all you want to do is display some text it'll probably work fine across most versions of Android. If you are using some bleeding edge API you may have some issues.

The "lets just release it" strategy isn't terrible. It's a trade off between your dev time of finding bugs pre-release and having users find them and what the impact is. If you take money you should make sure that process work on any version of your app that supports it. If the payment screen has some weird visual bug but functionally it works fine then it's probably okay for users to find.

Cover your core cases on all versions you support, things outside of that can probably be passed on to users safely.

</comment><comment><USER3> If your code fails on 100% of devices, testing with 1 device will catch it.

If your code fails with 99% of devices, testing with 5 different devices will almost certainly catch it.

Etc.

Which is to say, you won't catch obscure bugs, but you'll catch wide-spread bugs. And wide-spread bugs are exactly the ones you want to catch before general release.

</comment><comment><USER4> Depends what kind of testing you're talking about. Tech / does it work testing should be pretty easy to accomplish regardless of users/phones available. UX testing is a lot harder and probably better to do a combo of "just release" with recruiting testers.</comment>


Ask HN: How did you make your first million dollars? - <AUTHOR>

Let's discuss... <comment><USER2> Nearly every person I have met who has over one million dollars in assets did so slowly by making good investment decisions and a consistent, high-paying employment track record.

Sorry for the boring answer.

<comment><USER3> Consistent, high-paying employment here as well, paired with consistent investing in stocks.

I got pretty well smacked down in 2000 and again in 2008, but still crossed the 7-figure mark around age 40 even in spite (I would argue because) of the volatility and risk in the stock market.

<comment><USER4> good on you haha

my family invests stocks as well and we lost ~40000 in 2008, those were not good times.

</comment></comment></comment><comment><USER5> 1.) Graduated from a top engineering school with little debt ( ~$10k ) thanks to wonderful parents who planned from day one to send my sisters and I to our top choice colleges.

2.) Consulted, tutored, did odd jobs throughout school to help pay for living costs and continued this for my first year out of college while I worked at a large engineering company ( one year out and I had saved ~$40k, which > than a year's expenses at the time ).

3.) The $40k allowed me to take a risk and join a smaller company in the financial/software space that was offering half the salary other companies were offering, but with very good upside potential.

4.) Company has been doing very well -- much better than I anticipated. I invested my earnings well ( avg'd just over 20% return per year since I started investing during the turmoil in 2008 --- took very little, IMHO, investing risk --- turns out obsessive-compulsive tendencies can be put to good use digging into and understanding 10k reports ). I made my first million before I turned 30 and have multiplied that a few times over in the next few years doing pretty much the same thing. There was no one event that dropped a bunch of cash in my lap. I accumulated ( and continue to accumulate ) cash ( at an increasing rate --- snowball effects are amazing ) over time. Still cranking away.....

Best advice I can give for those who want to accumulate wealth. Find something you enjoy, can reward you well financially, and then grind it out for a decade. The last part isn't talked about that much because, well its generally not all that glamorous --- but I enjoyed it.

</comment><comment><USER6> I started a software business in 2003 catering to mortgage brokers. Sold it in 2008 for 7 digits. I have been managing it since then which bores me. I like to control my own path so I just handed-in my resignation and will start another software business.

I'm 54 and don't let anyone tell you you're too old, or any one of the other million excuses. Backing yourself is the only true security.

<comment><USER7> I've been trying to think of products for the mortgage or real estate industries for a while. Do you happen to have any ideas you'd like to share? Or advice on finding ideas?

<comment><USER6> Best bet is to phone-up and meet a few brokers and ask about their work, stresses, and pain. You may be lucky and a common thread may surface. If it does, then you know your path. Following the pain is a great way to get ideas.

When I started I didn't know a mortgage from a hole-in-the-wall (I came from telecom) and sent emails to every local mortgage broker. I met-up with a very cluey broker and that was the start.

You cannot think of ideas in a vacuum. You need to talk to the people in the trenches. Good luck.

</comment></comment></comment><comment><USER8> Every person I know that has a million dollar net worth is either an entrepreneur or business owner.

<comment><USER3> I suspect that you know a lot more people with a million dollar net worth and just don't realize it.

A million dollar net worth is often externally indistinguishable from "suburban family just barely making ends meet". In fact, invisible millionaires are less likely to have a flashy new car in a huge McMansion garage than the "barely making it" crowd is, IME.

<comment><USER9> This is in the Million Next Door, kind of theme. [http://en.wikipedia.org/wiki/The_Millionaire_Next_Door](http://en.wikipedia.org/wiki/The_Millionaire_Next_Door)

<comment><USER3> Thanks. I knew I'd read it ages ago, but couldn't place it.

</comment></comment></comment></comment><comment><USER10> I know a guy who bought AAPL at about $8 a share a while back and still holds a lot of shares, was part of the initial Dell IPO and also recently complained about only making 10x his Tesla shares so far. He's quite well set for a guy who invests as a hobby.

</comment><comment><USER11> I'm working on my second million... gave up on the first one a while ago.

</comment><comment><USER12> Managed to sell a disputed ancestral property.</comment>


Google CEO Tells Staff China Plans Are 'Exploratory' - <AUTHOR> https://www.bloomberg.com/news/articles/2018-08-17/google-ceo-is-said-to-tell-staff-china-plans-are-exploratory <comment><USER2> Translation:

"We'd really _really_ like to go back there, and we are willing to do whatever they ask of us (proven by all the reported ways in which we tried to convince the Chinese leaders to let us back in), but it's still their call whether or not to let us in, so what I'm trying to say is we're just "exploring" the option."</comment>


Ask HN: Digital Ocean Droplet or Dreamhost VPS? - <AUTHOR> I haven't looked into this problem space for a long while, but I'm helping a friend out, and in the past I would've looked at Dreamhost VPS, but Digital Ocean, especially with it's ECR-like image support looks really appealing - and cheaper!
Does anyone have any recommendations or experiences they could share?
Thanks :) <comment><USER2> DreamHost's main business seems to be shared hosting for Shitpress sites (and the security issues that involves).

Based on that alone I'd recommend staying away.</comment>