YAML: probably not so great after all (2017) - <AUTHOR> https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html <comment><USER2> One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usable? These were all questions. Seen in context, we got quite a bit correct. And yes... it has a few embarrassing warts and a few deep problems. Ah well.

A second thing to consider... YAML was created before it was common that tech companies actively contributed to open source development. There are lots of things we could have done differently if we had more than a few hours per week... even a tiny bit of financial support would have helped.

Finally, YAML isn't just a spec, it has multiple implementations. Getting consensus among the excellent contributors is a team effort, and particularly challenging when no one is getting paid for the work. Once you have a few implementations and dependent applications, you're kinda stuck in time.

It was an special pleasure for me to have had the opportunity to work with such amazing collaborators.

We did it gratis. We are so glad that so many have found it useful.

<comment><USER3> Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below).

* I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

<comment><USER4> You know what else is human readable, easy to parse if you're using PHP, and supports comments?

PHP.

I understand why _some_ languages rely on common configuration file formats.

I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.

<comment><USER5> You can use arbitrary tools to programmatically generate YAML (or JSON, or XML, any of the other "data only" formats.) This allows for tools to drive other tools by generating a spec file and feeding it in. See e.g. Kubernetes for a good example of that.

There's no language that I'm aware of that can natively generate PHP syntax, and there's no common multi-language-platform library for generating PHP syntax. I think that's most of the reason.

To contradict myself, though: Ruby encodes Gemfiles and Rakefiles as Ruby syntax. And Elixir encodes Mixfiles, Mix.Config files, Distillery release- config files, and a bunch of other common data formats as Elixir syntax.

And, of course, pretty much every Lisp just serializes the sexpr representation of the live config for its config format (which means that, frequently, a lot of Lisp runs code at VM-bootstrap time, because people write Turing-complete config files.)

<comment><USER4> > There's no language that I'm aware of that can natively generate PHP syntax

This is a solid argument against using PHP (or any such language) as a cross- language data interchange format. There are others :) And I totally agree you want a language independent format for anything you might have to feed across an ecosystem of tools.

For a PHP-system generating/altering its own config files... PHP's `var_export` generates a PHP-parseable string representation of a variable (though it sadly doesn't use the short array syntax).

Turing-complete config files probably have some hazards, like Lisp itself does. YMMV regarding whether those hazards can be avoided by circumspect developers or need to be fenced off.

<comment><USER6> You don't know when you'll need to generate or parse your config files with something that either can't read, write or execute your language.

Django's settings.py sucks. I've used Django since the 0.9 days. It's extremely impractical and needs to be worked around constantly.

<comment><USER7> Settings.py is uniquely bad, though, IMO because it tries to be a badly defined dict(), instead of exposing proper configuration interfaces. Ruby config files are common and usually fairly great, see for example the Vagrantfiles.

And you won't have to generate your config files (parsing, maaaaaybe), because those needs are covered by the fact that the files are programs. They are _already_ generating a configuration.

<comment><USER5> > And you won't have to generate your config files (parsing, maaaaaybe), > because those needs are covered by the fact that the files are programs. > They are _already_ generating a configuration.

Yes, theoretically, if settings.py was a "generator" format that you ran as a pre-step (like you do to get parser-generators like Bison to spit out source files for you to work with), and this generator actually spat out something like a settings.json, _and_ all the rest of the infrastructure actually dealt with the settings.json rather than the generator, _then_ , yes, it wouldn't matter. Tools in other languages could just generate the settings.json directly.

As it stands, none of those things are true, so tools in other languages actually need to do something that _outputs_ settings.py files.

<comment><USER7> Galaxy brain: if your config is programmable, it can read whatever terrible configuration format you want. That means my settings.py (yes, I'm forced to use Django) is configured via environment, which is populated by k8s from - _gasp_ \- JSON files.

That means that if I wanted to configure Vagrant with JSON, there is no force in the universe that could stop me.

If the config file is actually a normal program, then it can do normal program things, then any benefit from using JSON instead is nullified by the fact that you can still use JSON. In turn, if your tools primary configuration is via a more limited settings, you're stuck with it. Not even "generators in other languages" allow comparable runtime flexibility.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'd like to propose the "YAML-NOrway Law."

"Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway."

Example:

      NI: Nicaragua
      NL: Netherlands
      NO: Norway # boom!

`NO` is parsed as a boolean type, which with the YAML 1.1 spec, there are 22 options to write "true" or "false."[1] For that example, you have wrap "NO" in quotes to get the expected result.

This, along with many of the design decisions in YAML strike me as a simple vs. easy[2] tradeoff, where the authors opted for "easy," at the expense of simplicity. I (and I assume others) mostly use YAML for configuration. I need my config files to be dead simple, explicit, and predictable. Easy can take a back seat.

[1]: [http://yaml.org/type/bool.html](http://yaml.org/type/bool.html) [2]: [https://www.infoq.com/presentations/Simple-Made- Easy](https://www.infoq.com/presentations/Simple-Made-Easy)

<comment><USER2> The implicit typing rules (ie, unquoted values) should have been application dependent. We debated this when we got started and I thought there was no "right" answer. Alas, Ingy was correct and I was wrong.

<comment><USER8> I appreciate your humility and professionalism in a discussion thread that holds a lot of criticism; suffice it to say, I should have practiced a bit more humility and a bit less "Monday morning quarterbacking" in my original post. And I should have read your comment on YAML's history. To right the record: you got _so_ much right with YAML, and it's unfair for me to cherry- pick this example 20 years later. Sincere apologies...

As the saying goes, "there are only two kinds of languages: the ones people complain about and the ones nobody uses." YAML, like any language, isn't perfect, but it's withheld the test of time and is used by software around the world—many have found it incredibly useful. Sincere thanks for your contribution and work.

<comment><USER9> As someone who doesn't really use YAML much, your comment provides a good introduction to the kinds of things one needs to know before choosing formats in the future.

</comment></comment></comment></comment><comment><USER10> A thread hating on YAML without a mention of the bastardized YAML that ansible uses?

Ansible extends yaml so that:

cmd: a b c

is actually but not quite identical to:

cmd: ["a", "b", "c"]

It also embeds JINJA2 templating part-way (!) through the YAML parsing process.

The gotchas that these and other bastardizations cause is only partially documented at the bottom of this page: [https://docs.ansible.com/ansible/latest/reference_appendices...](https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html)

I like ansible, but its decision to use a bastardized YAML is a major pet peeve of mine.

<comment> crooked-v Ansible would be so, so much better if it just used plain JSON, or even JS with an implied context for variables, .eslintrc.js style.

<comment><USER11> You can usually use plain old JSON anywhere where YAML would be used (e.g. host vars, group vars, vars file includes, I think even playbooks). And internally, most everything in Ansible is JSON anyways.

YAML is for convenience for hand-editing configuration/task files; if you're doing anything that doesn't require hand editing/readability, use JSON.

</comment></comment></comment><comment><USER12> With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end.

In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma.

The only good thing I can see about YAML is that it's super easy to convert and re-export to JSON.

<comment><USER13> > In contrast, JSON is super intuitive and basically self documenting. The > only real quirks are that you need to use double quotes, and objects can't > have a trailing comma.

I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.

<comment><AUTHOR> JSON5 supports comments, and is only slightly more complex than JSON. [https://json5.org/](https://json5.org/)

<comment><USER14> The barrier here would be whether there's support in enough implementations to feel safe using it in the wild, which I'm guessing will take a while at the very least.

<comment><USER15> What's incredible here is that we're not at the beginning of programming, when we built temporary languages that ended up becoming forgotten. Web _may be_ a final form of IT, Angular may be the « right », the final, the perfect way to build applications even in 50 years, just like HTML has become the final way to build websites for the last 25 years, JSON may make legacy, and my grandson might even struggle with parsers that still use JSON instead of this new tech called JSON5...

</comment></comment></comment></comment></comment><comment><USER16> Years ago I had to support a tool that used YAML as a configuration language, and a transport between different applications. Holy. Hell.

First of all, don't ever try to edit a YAML file by hand. You _will_ introduce whitespace or other characters that will break the file, and you _will not know_ until you run it and it breaks something.

The reason you will not know? _Not all YAML parsers are the same._ Some will interpret it correctly, and some will break. You'll have to get reference implementations of every "supported" YAML parser and run every config you have through them all, and diff them all, before you can trust them.

YAML may be easier to read than JSON, but its added complexity (the parser is significantly more complicated) and obtuse "features" are just not worth the effort. Not to mention, have you ever tried to maintain a very large indented YAML file by hand? Pain in the ass. Just shove everything into JSON files. The fact that it's so limiting is freeing, and everything can parse it. But don't edit it by hand.

And IMNSHO, you shouldn't use _either_ YAML or JSON as a configuration language. They are for data structures, not configuration. If you want a configuration language, go get something designed as a configuration language.

<comment><USER15> Well your last sentence is the whole point: What is a sensible configuration language? For example what would have been decent for Ansible?

<comment><USER17> A lot of JS tools now will just take a js file that exports a configuration object (`.prettierrc.js`, `.eslintrc.js`, `.babelrc.js`). I find it very sensible.

\- Allows code reuse.

\- Allows configuration to be as dynamic as you want.

\- Can use environment variables.

I suppose there are some cases where you can't trust the user in this way (running configuration code), but I think in a lot of cases you can, and it's generally more convenient.

</comment></comment></comment><comment><USER18> No body talks about SDLang (Simple Declarative Language) : [https://sdlang.org/](https://sdlang.org/)

An example :

```

        // This is a node with a single string value
        title "Hello, World"

        // Multiple values are supported, too
        bookmarks 12 15 188 1234

        // Nodes can have attributes
        author "Peter Parker" email="firstname.lastname@example.com" active=true

        // Nodes can be arbitrarily nested
        contents {
        	section "First section" {
        		paragraph "This is the first paragraph"
        		paragraph "This is the second paragraph"
        	}
        }

        // Anonymous nodes are supported
        "This text is the value of an anonymous node!"

        // This makes things like matrix definitions very convenient
        matrix {
    	1 0 0
    	0 1 0
    	0 0 1
        }

```

<comment><USER19> One thing I dislike about it at a glance is:

        author "Peter Parker" email="firstname.lastname@example.com" active=true

This is like XML attributes, which I've always found annoying to deal with in programs. It doesn't really map to any native data structure in most (all?) programming languages, so you need a special class/struct which supports it.

Simply using something that maps directly to a hash map/object/associative array would be much better, IMHO.

Other than that, it looks like an interesting project.

<comment><USER20> Actually it is even a superset of XML, from the docs...

        SDL documents are made up of Tags. A Tag contains

        * a name (if not present, the name "content" is used)
        * a namespace (optional)
        * 0 or more values (optional)
        * 0 or more attributes (optional)
        * 0 or more children (optional)

So it's like an XML node, but the `0 or more values` means it has a list/array for a "body".

<comment><USER18> At least on the case of DLang implementation, uses a DOM api to access to the values. [https://github.com/Abscissa/SDLang-D/blob/master/HOWTO.md](https://github.com/Abscissa/SDLang-D/blob/master/HOWTO.md)

</comment></comment></comment></comment><comment><USER21> I'm gonna continue using YAML, like, even if each parser came with support for a halt-and-catch-fire directive that you couldn't turn off or whatever. It's just about the only markup language where you can embed multiline strings without the indentation being fucked either in the markup or in the resulting string, without requiring lots of escaping.

</comment><comment><USER22> I am sad that EDN hasn't achieved popularity as a format. It seems like a better specified, less verbose format. As a bonus it plays well with Paredit- like editor modes. Alas, the curse of being better, but later.

<comment><USER23> EDN is nice, but the curly brackets are a hassle when editing configs. That's why I prefer using yaml to configure my Clojure apps.

</comment></comment><comment><USER24> We've spent like 10 years trying to fill in gaps left when we all decided to hate XML. JSON is great as a lightweight DIF between trusted partners. If you care about maintenance and safety, XML with XSD is rock solid.

<comment><USER25> I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this:

       <parameter>
         <name>ApplicationName</name>
         <value>WhizBang</value>
       </parameter>
       ...

So that they could pass schema validation and still have some hope of extensibility.

<comment><USER26> Why not just

<parameter name="ApplicationName" value="WhizBang"/> ?

<comment><USER27> That's the age-old question, isn't it?

Your option is better, but XML is very (maybe too) flexible and is bound to be made a mess of.

<comment><USER26> I've seen some pretty messed up schemas in JSON and YAML, too.

</comment></comment></comment></comment></comment><comment><USER28> A couple thoughts.

If your configuration file is so long it's unreadable in YAML, then maybe you need to break it up into more than one file? I can't imagine any syntax would be easy to read once you reach more than 100 or so lines.

Do any configuration file languages support type hinting? Adding (int) in front of a YAML key would be easy enough to read, and would keep some of the confusion at bay.

<comment><USER29> YAML tags work this way. E.g., 2002-04-28 is a date (because it looks like one) but !!str 2002-04-28 is a string.

<comment><USER28> I had never heard of tags before. Thanks!

So, would this work?

        ports:
          https:
            enabled: yes
            !!int port: 443

Then if someone is copy/pasting and tries to use "blah" as the value, the !!int tag would cause the yaml parser to throw an error. Right?

<comment><USER30> No, because tags specify a type for the value, not the key, so you could use

      ports:
        https:
          port: !!str 443

to parse the same as

      {
        "ports": {
          "https": {
            "port": "443"
          }
        }
      }

in JSON

<comment><USER28> Ah, I had my syntax wrong. Thanks!

</comment></comment></comment></comment></comment><comment><USER31> As a general rule of thumb: Never use yet another non-markup language designed by people who claimed to be designing yet another markup language from the very outset, then after somebody awkwardly pointed out that what they'd designed wasn't actually a markup language, they invent a backronym to contradict that embarrassing historical fact.

It just makes me wonder what the hell they thought they were doing all that time...

It's like designing a tool called YACC, and ending up with Yet Another Interpreter Interpreter!

It's like a standard for storing all your pornography in a folder called "Definitely Not Pornography".

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

>Originally YAML was said to mean Yet Another Markup Language, referencing its purpose as a markup language with the yet another construct, but it was then repurposed as YAML Ain't Markup Language, a recursive acronym, to distinguish its purpose as data-oriented, rather than document markup.

<comment><USER2> > It just makes me wonder what the hell they thought they were doing all that > time...

The YAML project was a convergence of several different efforts at information representation including people from Perl, Python and Ruby, each with our own ideas. I happened to be involved in the outer ring of the XML community, in particular a group SML-DEV where we were looking for a better information model more suitable to data serialization that would use an XML compatible syntax.

At that time, especially since serializing data with XML was all the rage, "ML" or "Markup Language" was commonly associated with data serialization. In fact XML is very inconvenient for actual markup, even though it derives from SGML (of which HTML is an example).

The "YA" part did deliberately come from YACC, the reason why is that XML (and we hoped YAML) would be the basis of domain specific serialization languages. Hence, you can think of it as a meta-language for building sub-languages, like the application I was working on, a serialization for accounting data.

Hence, that's the origin of YAML acronym, which happened to have a domain name open. In fact, you can look at archive.org starting in 2001 and you'll see the 1st public pass of YAML more closely followed XML like bracket syntax. I disliked it, but, it was what came out of the SML-DEV collaborations. Even so, the important thing was the information model, which was a simple typed graph and not an element tree.

The syntax evolved with many revisions after the model and goal were set, with lots of feedback to address concerns and usability tests with domain experts. The syntax got more and more lightweight, inspired from RFC0822 (email) while adding dashes for list items. Testing the syntax with domain experts, e.g. accountants and the like, was exceptionally important part of the process. Users liked this serialization syntax since it made their data "pop".

So. A year or so passes while we focus on getting things to work and helping people. Then, the product differentiation question comes up. Since XML had the dominant position in the data serialization mind share, how does YAML compare? Well, the YAML model was a typed graph, while XML was an element tree. One required no special libraries to manipulate, the other require a DOM to translate. But perhaps more importantly, it's because XML borrowed its model and tags from SGML and SGML was a true "markup language". So, XML was a "markup language" where it was impractical to do actual markup. Then, it dawned on us, well, of course a data serialization language isn't markup problem. I'm not sure any of this was obvious at the time.

Anyway, in a very fun chat, Oren pointed this out and then Ingy said: well then, YAML Ain't Markup Language! So, the new name actually represented what we had set out to do in the first place. Further, I would suggest that the industry understanding of how serialization languages are poorly supported by markup approaches (XML) is at least somewhat due to our name change and fun filled articulation at conferences.

</comment></comment><comment><USER32> For config formats I'm finding HCL[1] to be nice for my use cases. It has comments, no requirement for double quoted identifiers, and is actually simple. The main issue was the only implementation is in Go, so I had to write a port to C++.

[1] [https://github.com/hashicorp/hcl](https://github.com/hashicorp/hcl)

<comment><USER33> Super happy with HCL for over a year in production now.

I've only got one FOSS project using HCL but I think of its' bundled HCL config file is an attractive part of its UX: [https://github.com/LukeB42/psyrcd](https://github.com/LukeB42/psyrcd)

</comment></comment><comment> crooked-v I continue to hold a firm belief that the reason JSON is so popular is that it covers most use cases without any of the dumb crap that hides in YAML and XML behavior.

<comment><USER34> Yes. YAML and XML do way more than a config format needs. You need key value pairs and basic structures (variables, arrays and maps) and types.

JSON is lacking in some respects but it's still really close to perfect for its use case.

</comment></comment><comment><USER35> Over the past few months, I've built up a somewhat masochistic relationship with YAML, as I've been writing my own JS library for it [1]. Yes, the spec is more complicated than it ought to be and yes, writing yet another implementation might just mean more overall variance within the spec, but it's still the only config language with decent usage that supports human-readable multi-line strings and comments. And it would've been really nice if someone else had supported editing comments, so I wouldn't have needed to do that myself.

Still, I'm optimistic, especially now that Prettier is getting YAML support. [2]

[1] [https://eemeli.org/yaml/](https://eemeli.org/yaml/)

[2] [https://github.com/prettier/prettier/pull/4563](https://github.com/prettier/prettier/pull/4563)

</comment><comment><USER36> For a serious take on configuration file format it might be worth checking out Dhall.

Dhall has schemas, types, imports, and even functions (though it doesn't let you write code that would e.g. loop infinitely).

You can even use an executable[0] to compile Dhall to YAML and JSON, excluding unsupported features such as functions.

[0] [https://github.com/dhall-lang/dhall- lang/blob/master/README....](https://github.com/dhall-lang/dhall- lang/blob/master/README.md#json-and-yaml)

</comment><comment><USER37> I agree with some of the author's points but the "surprising behaviour" section is odd. For example, why would you expect `3.5.3` to be parsed as a number? How could that be parsed as a number?

<comment><USER38> The 013 to 11 issue is pretty obvious to any seasoned programmer. For example C, Ruby, and yes, also Javascript have the same "problem".

Octal 13 is decimal 11.

JSON should actually have the same issue. When I enter { 013: "11" } in the web console I get '{11: "11"}'. And YAML is backwards compatible to JSON.

That's IMO the actual problem of YAML. It could have supported a reasonable subset of JSON and not the whole nine yards.

<comment><USER39> The web console is not a JSON parser. To check if something parses as JSON in the web console you should use JSON.parse, e.g:

      JSON.parse('{ 013: "11" }')

which should produce a syntax error (as already mentioned by siblings to this comment).

<comment><USER38> Thanks. Yeah, I had mistakenly the believe that JSON is mostly a Javascript hash, not that 'JSON is valid Javascript' which means it's a subset of all possible Javascript hashes.

</comment></comment></comment></comment><comment><USER40> Every time this comes up, I don't understand how [https://json5.org](https://json5.org) isn't superior to YAML in every way.

If there was some deficiency with JSON5, just simply use JSON with comments. It's that simple.

JSON is one of the best things to ever come out of the CS disciplines.

For those that whine about comments in JSON, Douglas Crockford, the creator of JSON, himself said to do it.

>Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

</comment><comment><USER41> I never understood what it is that people like about YAML.

I keep configuration in EDN, which avoids all of the problems described in the article and has other advantages, too.

<comment><USER42> EDN is fantastic. It wasn't super portable last I looked though.

<comment><USER22> There is reasonably good library support: [https://github.com/edn- format/edn/wiki/Implementations](https://github.com/edn- format/edn/wiki/Implementations)

</comment></comment></comment><comment><USER43> I personally dislike with a passion every language or grammar that depends on white-space identation, especially if the designers were extremely opinioned to the degree that you can only use spaces (or even, a specific number of spaces per identation level) and not tabs.

It's not as a big of a deal in Python because as others have mentioned, you usually don't end up writing large functions to begin with, and tab identation is supported. It still means that if you try to send a code snippet to someone over email or Slack, IM, etc it may not work because whitepsace may be trimmed etc. With YAML, it's way worse for reasons the author outlined.

Something may look good on paper (or in screenshots) but practical considerations need to factored in when designing a grammar, and there are myriads pretty-formatting utilities that could be used to that end if one cares for that sort of thing (see also: clang-format).

</comment><comment><USER44> I don't love YAML, but for configurations I always choose it for the simple fact that it supports comments. Comments for json are almost always hacky (for example, imbedding a comment key inside the value).

</comment><comment><USER45> I write a lot of command line tools for work and need configuration files and always go for YAML, but am never happy about it. I use it because it serializes to Ruby objects so I can more easily do validation and check if someone forgot an important key but I wish there were something that would make that easier for the people using the config files. I looked into TOML after this and liked what I saw.

</comment><comment><USER46> I've been playing with Home Assistant[0] recently and, as a result, getting exposed to YAML. I don't find it pleasant to work with at all. I'm sure a big part of that is how Home Assistant uses YAML for automation stuff[1] that would probably be better served by a real programming language.

I think a big part of the unpleasantness comes from how non-obvious some things are. For example, why does the first automation example require a "-" in front of "platform" (under "trigger"), but the second doesn't? The comments explain _when_ it's required, but not _why_? Shouldn't the parser be able to figure it out from the significant whitespace?

I found it so unpleasant that I'm using Node-RED[2] to do anything even vaguely automation related and have relegated Home Assistant to being the UI and communications abstraction layer.

In contrast, XML, while overly verbose, has a more reasonable structure. I haven't played with JSON much, but it also seems pretty reasonable.

[0] [https://www.home-assistant.io/](https://www.home-assistant.io/)

[1] [https://www.home- assistant.io/docs/automation/examples/](https://www.home- assistant.io/docs/automation/examples/)

[2] [https://nodered.org/](https://nodered.org/)

<comment><USER47> (Founder Home Assistant here)

Everything that you can do in YAML + more, you can do in Home Assistant using Python. Have a look at my PyCon talk [1] from 2 years ago or check the available functions in the docs [2].

About the dashes. In Home Assistant when an option takes a list, you can omit the list if you are just passing in a single entry.

[1]: [https://youtu.be/Cfasc9EgbMU?t=1038](https://youtu.be/Cfasc9EgbMU?t=1038) [2]: [https://dev-docs.home- assistant.io/en/master/api/event.html](https://dev-docs.home- assistant.io/en/master/api/event.html)

</comment></comment><comment><USER48> > Are you sure that every YAML parser will treat foo:bar as a string, or 0x42 > as the integer 42, etc.?

Definitely not. I'd expect 0x42 to be 66. (Not kidding, if 0x42 means hex notation!).

Point taken.

<comment><USER49> My friends who are smarter than me have these criticisms.

XML -> doesn't record what programs think of as 'data'. So a program needs to convert it's data representation to XML and back again. Usually there is no formal spec. This is the exact same issue you have with databases. But at least a database has a formal representation and data types.

Part of SOAP is Microsoft trying to bolt schema's onto XML. SOAP seems to generate a lot of unhappy programmer noises. But my ex roommate said, 'well when you get it working it works'

JSON and YAML do but they don't have schema's to parse against. So programs need to do their own validation.

</comment></comment><comment><USER50> > Loading a user-provided (untrusted) YAML string needs careful consideration.

Why would you ever use YAML for user-provided input? At that point, it's better to just use JSON.

> Many other languages (including Ruby and PHP1) are also unsafe by default. > Searching for yaml.load on GitHub gives a whopping 2.8 million results. > yaml.safe_load only gives 26,000 results.

Maybe that's everyone's using JSON where it would be unsafe to use YAML.

> YAML files can be hard to edit, and this difficulty grows fast as the file > gets larger.

And... this isn't the case for XML or JSON?

Ok, so reindenting a section might be a pain, but if your YAML is containing large amounts of data, maybe that data doesn't belong in that format if you're manually editing the YAML.

> especially since 2-space indentation is the norm and tab indentation is > forbidden

Good. ;)

> And accidentally getting the indentation wrong often isn't an error; it will > often just deserialize to something you didn't intend. Happy debugging!

Which is unlikely to happen if you're using a YAML library or only editing small-ish config files by hand.

\---

As noted, YAML has a lot of quirks. As a configuration language, I love it and am used to the little edge cases. Could it be better? Definitely. But I would still consider YAML to be great in the domain where it excels: human-readable configuration. Using it to store and transmit large amounts of data, especially in ways where a human is manually editing the YAML, is a terrible idea.

</comment><comment><USER51> Since we're all chiming in with configuration formats, here's two more nice ones:

1\. If you're writing Lisp, just read S-expressions in.

2\. Use Python or Skylark and have a step that executes it into a configuration format. Obviously this is not something you would want to use for a data interchange format, but no one thinks that they can blindly run a random hunk of untrusted Python. Right? ...Right?

</comment><comment><USER20> One of the important things implementations failed to do was properly support Schemas ([http://yaml.org/spec/1.2/spec.html#Schema](http://yaml.org/spec/1.2/spec.html#Schema)). And this is still the case today. Had they done so, the safe load issue would never have arose, and the loaders/dumpers would be properly configurable to suit the needs of the application, e.g. don't support "Yes" and "No" as `true` and `false`.

I once did about 98% of the work to support Schemas properly in Psych ([https://github.com/ruby/psych](https://github.com/ruby/psych)) but the maintainer said he didn't want to "maintain it".

So, there you go. What else can one do? You can't blame the spec for decisions of implementors.

(That's not to say the YAML spec couldn't use some improvements, but it's far from "not so great".)

</comment><comment><USER52> Yes, I love YAML in general. The complaints about big files can be alleviated with a good editor that collapses blocks and draws indentation guides.

But the author is mostly right, when adding support for YAML to my code I spend a lot of time disabling all of its nifty misfeatures. Wish it was simply an indented JSON with comments and fewer quotes.

</comment><comment><USER53> We recently published a paper suggesting an alternative to HDF5 [1] using directories for objects, YAML for metadata and NumPy for data. Many of the points in this article were raised by the reviwers or were worries we had about choosing YAML as the metadata format. In the end, we decided to use a subset of YAML with only basic tags, enforced quoted strings, no directives, and no block scalar styles (fancy multiline strings). So far it has worked out great. I hope it will make the format easier to understand for users and make it possible to write faster parsers in the future.

[1] Shameless plug: [https://www.frontiersin.org/articles/10.3389/fninf.2018.0001...](https://www.frontiersin.org/articles/10.3389/fninf.2018.00016/full)

</comment><comment><USER54> YAML and TOML both seem too complicated. Automatic date parsing? So many different ways to specify the same nested hash table? I like json because there's usually one obvious way to do what you want. It's a local minimum, like C and Lisp. It's really too bad about the comments.

<comment><USER55> Way too much engineering time and energy has gone into handrolled, mutually- incompatible solutions for passing dates in JSON.

</comment></comment><comment><USER56> What about Toml , I like it.

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

<comment><USER57> He literally recommended that as an alternative in the article.

</comment></comment><comment><USER58> > Don't get me wrong, it's not like YAML is absolutely terrible – it's > certainly not as problematic as using JSON – but it's not exactly great > either.

Well at least it's the least worst then, do that make it the best?

Frankly I hope the future will be make with indented languages. Curly braces languages often allows too much liberty, and it's annoying. The fact that go enforce the curly brace style is really the tipping point of curly brace languages.

Granted there need to be some good compromise for ambiguous details when parsing an indented syntax, but readability matters much more than anything to me.

<comment><USER59> I like the "Ruby approach" of:

        if foo
            ...
        else
            ...
        end

It solves some of the issues that you can have with Python, while at the same time also avoiding the whole nonsense with the braces. I find it's a good trade-off between the strengths of both approaches.

</comment></comment><comment><USER60> If the problem YAML is size / formatting, that's something a good IDE can simplify even more. For loading up configs that would otherwise be properties files, I have found it to be quite clean. If you think of it a domain language for configuration, YAML is great. It can be understood pretty much intuitively, and it does some things quite well. On the other hand, when it comes to exchanging data, JSON > XML > X12 EDI... EDI? Yes, it's still a thing... a terrible thing...

</comment><comment><USER31> I recently posted about a technique I've been developing (and am very happy with) for representing and editing JSON in spreadsheets, without any sigils, tabs, quoting, escaping or trailing comma problems, but with comments, rich formatting, formulas, and leveraging the full power of the spreadsheet.

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

>Recently I've been working on kind of the converse of this problem with JSON and spreadsheets, and I'll briefly describe it here (and I'll be glad to share the code), in the hopes of getting some feedback and criticism:

>How can you conveniently and compactly represent, view and edit JSON in spreadsheets, using the grid instead of so much punctuation?

>The goal is to be able to easily edit JSON data in any spreadsheet, copy and paste grids of JSON around as TSV files (the format that Google Sheets puts on your clipboard), and efficiently import and export those spreadsheets as JSON.

>[...]

Since I wrote that post, I've cleaned up and refactored the code into a portable little library that will run in the browser, or inside of Google Sheets:

[https://github.com/SimHacker/UnityJS/blob/master/UnityJS/Ass...](https://github.com/SimHacker/UnityJS/blob/master/UnityJS/Assets/StreamingAssets/sheet.js)

Here's an example spreadsheet (also check out the examples in the other sheet tabs):

[https://docs.google.com/spreadsheets/d/1nh8tlnanRaTmY8amABgg...](https://docs.google.com/spreadsheets/d/1nh8tlnanRaTmY8amABggxc0emaXCukCYR18EGddiC4w/edit?usp=sharing)

I haven't come up with a trendy marketing name for it yet (except for the source file name sheet.js), because I think it's important to first discover what it is by using and refining it for a while, writing some documentation to explain it, and getting feedback from other people (work in progress), before trying to name it -- otherwise you might end up calling it "Yet Another <something it's not>".

</comment><comment><USER61> Not agreeing or disagreeing, but I read both this and his other post about JSON as configuration file and I have not seen him propose and argue for an alternative.

<comment><USER62> He doesn't have to propose an alternative to have an opinion on it.

If I don't enjoy a movie, I'm under no obligation to suggest another. It's an opinion. It can stand alone.

<comment><USER63> In your analogy, the alternative is to not see the movie. The analogous alternative would be to... what? Not use config files? Doesn't seem like much of an alternative to me.

</comment></comment></comment><comment><USER64> > Can be hard to edit, especially for large files

How does this entire section not also apply to JSON?

<comment><USER59> JSON is slightly easier since you have actual start/stop marks in the form of `{`, `}`, instead of relying on 2-space indentation. (are there 8 or 10 spaces there? Hard to see).

</comment></comment><comment><USER65> The alternative of writing executable code as your config language also has it's own issues. It's why things like skylark was invented for buck & bazel:

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

</comment><comment><USER66> JSON + comments + trailing commas + naked keys + multiline strings would be a great alternative. Maybe something like JSON5.

<comment><USER67> You'd really like HOCON[0] then. Just a bit too complicated to see wide adoption I'm afraid.

0 - [https://github.com/lightbend/config/blob/master/HOCON.md](https://github.com/lightbend/config/blob/master/HOCON.md)

<comment><USER66> Interesting, but, as you wrote, it's a bit too much complex, and there is too much syntactic variations for my taste.

</comment></comment></comment><comment><USER68> We need to standardize cson ([https://github.com/bevry/cson](https://github.com/bevry/cson)) and build a compliant C parser. The format is simpler with fewer surprises as YAML, yet able to handle more types of syntaxes in a straightforward form.

</comment><comment><USER69> I came in here to rant that YAML _isn 't for the same purpose as JSON and XML_ but then thought I'd better RTFA and realised that _oh yeah one or two good points here_.

The first criticism, where he's embedding exectutable code in YAML I kind of have to agree with - that seems crazy. I don't know why YAML would support this.

The remaining criticisms seem to relate to (a) the spec overreaching in terms of complexity and (b) differences in implementation, which I guess is some kind of an extension of (a).

I maintain however that YAML, JSON and XML are different.

If you want to make me feel cross and insulted give me a JSON file to edit. I think JSON is probably the best commonly used format for M2M and storage serialisation.

I wouldn't want you to use YAML for that though. There's two many _different ways to do it_ and any kind of ambiguity never makes for good M2M.

For configuration-files it's great though, as long as you stay away from some of the more exotic features I suppose. It effectively provides a "user interface" of sorts by which your users can specify non-trivial configuration details.

The complaints about overlong and overcomplex yaml files could be extended to other commonly used formats.

With regards to XML, I'd say that YAML provides all the features you'd want to use from that format in a format that's easier to hand-edit as text. XML is "okay" for M2M but probably better for document storage where you have some kind of custom editor.

It's horses for courses. I wouldn't want to use YAML where I'd want to use JSON, or use XML where I'd use either of them, and neither of these have the semantic richness of XML either and so wouldn't be appropriate in whatever spaces XML should be used (which is far more limited I suspect than its current span of applications).

Ultimately when each is used to its strengths they're not interchangeable formats.

</comment><comment><USER70> I haven't found a markup language that I really prefer for configuration files, but JSON has been reasonably nice to me in NPM configurations and VS Code settings and I haven't ran into problems yet. I understand the motivation for TOML but it has the same ambiguity problems that YAML does. There's something to be said for not being _too_ flexible, or it'll fall into the same trap as AppleScript did. Humans might prefer the convenience of ultra- flexibility at first, but sooner or later our intuition will just not match up with the actual rules, and we'll have to spend longer than we wanted to looking up arcane syntax documentation. That's been my experience with YAML anyway, like every single time.

</comment><comment><USER71> A few considerations I do not agree with:

> YAML is insecure by default. Loading a user-provided (untrusted) YAML string > needs careful consideration.

That is trivial. Everything you execute that come from outside is potentially dangerous.

> It's pretty complex

I would say, that YAML is more expressive and has more features. On the other hand is true that TOML is a valid alternative in many use cases.

> 3.5.3 gets recognized as as string, but 9.3 gets recognized as a number > instead of a string

That is correct, in my opinion, 9.3 is a float while 3.5.3 is a version. If you want both to be strings, use quotes.

</comment><comment><USER72> > One might also argue that fixing it is as easy as replacing load() with > safe_load(), but many people are unaware of the problem, and even if you're > aware of it, it's one of those things that can be easy to forget. It's > pretty bad API design.

It is. At API design time, it would have been trivial to replace them with `load()` (which does the same as `load_safe()` now) and `unsafe_load()` (which does the same as `load()` now) and probably avoid this pitfall altogether. Now? Much more difficult to solve.

</comment><comment><USER73> For what it's meant to do (conscisely express data in a human maintainable way) it's still in a league of it's own. For configuring your apps, it's the way to go.

</comment><comment><USER74> I think this is a problem of trying to serve all use cases at once. I mean, if you're making a data exchange format, do you _really_ need it to be able to execute arbitrary code? Isn't that inviting trouble? It's like building a bank vault and then cutting a large hole in it and putting a plywood door on it - just in case somebody would want to convert it to a restaurant later. Maybe it would be better not to serve that particular use case at all?

</comment><comment><USER75> I'm not saying YAML is perfect or terrible (just like the author), however most of the examples the author gives are going to be the same for any language attempting to implicitly type values.

I think maybe YAML just went a bit too far: because everyone hates defining key names with quotes when it's unnecessary 99% of the time, but it would have been enough to relax that rather than go all the way to suggesting relaxing all quotes and then attempting to infer value types.

</comment><comment><USER76> Our shop are heavy users of YAML, and we've sort of backed our way into a restricted subset of YAML. Some of them are config files, but others function closer to DSLs.

I have not yet taken a look at strictyaml, but after years of use the spec definitely needs YAML, The Good Parts Treatment.

One thing the author did not mention was how slow the out of box the Python YAML parser can be. This can be sped up with a call to libyaml, but then you lose the safe_load method.

<comment><USER77> I suspect the speed issues are more a result of implementation details than of being in Python. Last year, I created a config language for my own use that supports some syntax very similar to YAML. My pure Python library can load simple dict/list/string data 10x as fast as PyYAML, and nearly within 1.5x the speed of libyaml ([https://bespon.org/#benchmarks](https://bespon.org/#benchmarks)). That's while building an AST with source information to allow round-tripping and supporting my own version of anchors and tags, so there's significant room for improvement. I expect that a pure Python YAML library might be able to match or beat the current performance of libyaml in at least some cases, particularly for a restricted subset of YAML.

<comment><USER76> I did a few rudimentary benchmarking tests on in house real world data sets and strictyaml was approx 10X slower than PyYAML's yaml.load (w/ out calling out to libyaml) and yaml.safe_load.

I used the basic strictyaml.load function, without any schemas.

README page said speed is not a current priority, and that appears to be true.

[https://github.com/crdoconnor/strictyaml#strictyaml](https://github.com/crdoconnor/strictyaml#strictyaml)

</comment></comment></comment><comment><USER78> Semirandom question: what's the proper file extension for a YAML file?

I've done informal polls on it and every time it's an _even split_ between .yaml and .yml

<comment><USER79> There are plenty of file formats that have multiple extensions in common use. I can think of a few off the top of my head:

\- .jpg / .jpeg

\- .tif / .tiff

\- .htm / .html

\- .cpp / .cxx

It's frustrating at times, but not all file formats have One True Extension.

<comment><USER80> C++ is the worst offender: .cpp, .cxx, .cc, .h, .hpp, .hh, etc.

<comment><USER79> I've even seen .c++/.h++ in the wild at least once.

<comment><USER29> Could be worse, could be uppercase .C/.H…

</comment></comment></comment></comment></comment><comment><USER81> I got blindsided by another obscure yml phrasing rule. Sometimes people couldn't pay online using our service and I couldn't figure out why. I tested the hell out of the payment module on our dev and UAT environments, but I just couldn't reproduce the issue.

Eventually I tracked it down to an ID inside a yml file. Turns out the live environment was running in 32 bit mode which interpenetrated the number as a string.

</comment><comment><USER82> As somebody who heavily uses statically-typed languages and serializers, I'm actually really enjoying reading about StrictYAML.

I love this bit explaining why schemas are essential to having a human- friendly config file:

[http://hitchdev.com/strictyaml/why/syntax-typing- bad/](http://hitchdev.com/strictyaml/why/syntax-typing-bad/)

</comment><comment><USER20> I hope YAML Implementers will read this and give thought to adding proper support for Schemas ([http://yaml.org/spec/1.2/spec.html#Schema](http://yaml.org/spec/1.2/spec.html#Schema)) -- they should be customizable by the application. This would resolve a number of complaints and improve interoperability.

</comment><comment><USER83> We used YAML from the start in Wrench tool for writing reftests for WebRender[1]. Currently looking into a prospect of migrating all of them to RON[2] as a better alternative, which has proven itself useful in WebRender captures.

      [1] https://github.com/servo/webrender/
      [2] https://github.com/ron-rs/ron

</comment><comment><USER84> Nothing is perfect and critiques always welcome. Will add the article to Awesome YAML - a Collection of Awesome YAML (Ain't Markup Language) Goodies for Structured (Meta) Data in Text [[https://github.com/datatxt/awseome- yaml](https://github.com/datatxt/awseome-yaml)]

</comment><comment><USER85> Honestly, I can't stand YAML. Every time I need to read a YAML file I also need to bring up a reference for what the syntax is because to me, none of it is immediately obvious.

Personally, I don't understand why all these projects have defaulted to using such an esoteric markup language.

</comment><comment><USER86> Yaml has a lot of features that I think need to be used sparingly.

But wow do I wish JSON supported comments in some form.

</comment><comment><USER87> I enjoy HOCON btw. Are there other configuration languages that any of y'all like?

<comment><USER73> There's this half baked one I built once because we wanted untyped config and had never heard of JSON

[https://github.com/EamonnMR/Zond/blob/master/RedShift/src/co...](https://github.com/EamonnMR/Zond/blob/master/RedShift/src/core/StringTree.java)

It ends up looking like this: [https://github.com/EamonnMR/Zond/tree/master/RedShift/assets...](https://github.com/EamonnMR/Zond/tree/master/RedShift/assets/text)

</comment></comment><comment><USER88> Surprised to see that few people mentioned this one advantage that JSON has over YAML: validation against a predefined Schema [1].

[1] [http://json-schema.org](http://json-schema.org)

</comment><comment><USER89> > it seems to be the case that the majority of libraries are unsafe by default > (especially the dynamic languages), so de-facto it is a problem with YAML.

It may seem that way, but it's not. Re: cryptographic functions

</comment><comment><USER90> Schemas and validation for YAML (and JSON):

[http://github.com/common-workflow- language/schema_salad](http://github.com/common-workflow- language/schema_salad)

</comment><comment><USER91> I hear the arguments, and I'd say YAML is unbeatable

\- when loaded safely

\- when used by humans to edit obviously structured data of hashes and arrays

\- and the humans are trained to double-quote potentially problematic entries.

This wins over xml or Json hands down.

</comment><comment><USER20> [https://zedshaw.com/archive/stackish-an-xml- alternative/](https://zedshaw.com/archive/stackish-an-xml-alternative/)

</comment><comment><USER92> I've used YAML for years, and yeah, there's a lot of warts, but I love it for small(ish) manually edited configuration files. I generally keep it simple and it works.

</comment><comment><USER93> Library comparison: [https://github.com/cblp/yaml- sucks](https://github.com/cblp/yaml-sucks)

</comment><comment><USER94> Is there something that looks like YAML, but with a smaller spec?

I know things like TOML and JSON, while they have good DX, for me YAML has the better UX.

</comment><comment><USER95> The most flexible configuration language is still a programming language. It allows you to define e.g. callback functions.

</comment><comment><USER96> Those reasons are exactly why I created mset. It's not as flexible as Yaml but it is dead simple and works for many use cases. It is also very easy to implement in any language and more importantly super simple to learn for end users.

[https://github.com/sed-seyedi/mset](https://github.com/sed-seyedi/mset)

</comment><comment><USER97> > What About:

> python: 3.5.3

> postgres: 9.3

> {'python': '3.5.3', 'postgres': 9.3}

Surely that's reasonable?

</comment><comment><USER98> Anyone here use Swagger? Do you write your definitions in JSON or YAML?

<comment><USER59> I generate Swagger/OpenAPI files, and use YAML because it's easier to read.

If I had to write OpenAPI files manually I'd probably choose to jump out of the window.

</comment></comment><comment><USER99> > {'Clemenza': True},

That actually made me laugh out loud.

</comment><comment><USER100> What should I use for config files?

</comment><comment><USER80> From a reddit comment: [https://www.reddit.com/r/programming/comments/8shzcu/yaml_pr...](https://www.reddit.com/r/programming/comments/8shzcu/yaml_probably_not_so_great_after_all/e0zwlx3)

Seems like YAML tried too hard to be predictive of intent. I never got into YAML myself simply because it seemed like "JSON, but less ubiquitous and more hassle to find libraries that support it"

</comment><comment><USER101> there should be a json standard with a header to describe the content.

also what was wrong with ini files?

</comment><comment><USER102> Object graphs are the answer to the endless iteration on the right config format:

[http://codesolvent.com/config-node/](http://codesolvent.com/config-node/)

it is however difficult to pull off and requires productization, in other words not low-level tooling in a text file.

<comment><USER103> > _difficult to pull off and requires productization, in other words not low- > level tooling in a text file._

Is this supposed to be a feature? One of the great things about simple config files is that you can use standard GNU tools to view edit, and diff them, you can put them in source control, you can be sure that you can edit them on a remote server no matter what's installed, etc.

Eliminating all those benefits would require an extraordinary jump in functionality as a tradeoff, a jump in functionality that most things frankly don't need.

<comment><USER102> You're right regarding the value of text files. ConfigNode is really for management of configurations for use cases where you can have huge JSON/YAML files and you want to be able to manage them, facilitate dynamism (often using templates)...support collaboration..etc...it is a gold-plated solution and not necessarily suitable for simpler needs.

Here's another example of ConfigNode used to manage Akamai configurations:

[https://youtu.be/gcPAmpKo9fs](https://youtu.be/gcPAmpKo9fs)

Akamai configurations can be very complex and need to be maintained and managed, you can't really do that effectively using text files.</comment></comment></comment>


Oolu (YC S15) Is Bringing Solar Energy to West Africa's Off-Grid Population - <AUTHOR> http://techcrunch.com/2015/07/31/oolu-is-bringing-solar-energy-to-west-africas-off-grid-population/ <comment><USER2> I really don't see why investors would be too interested, but good luck to you anyway. My company was going to build a $50mil solar farm in Nigeria and we couldn't find enough interest in funding anything like this. It seems like it would be a lot less hassle to focus on large solar projects... The general rule of thumb is that Americans are scared of investing in Africa, even though there is a lot of opportunity.

Maybe smaller solar installations like this would work out better than larges ones.

What are you going to do if someone doesn't pay up, are you going to take their solar lamps away from them?

<comment><USER3> I think the key part in the article may be this:

 _" Instead, the company's true feat is setting up a distribution model and payment infrastructure that West African families and community leaders are comfortable with."_

A distribution model that goes through community leaders has built-in trust. If someone steals the hardware, it will be known inside the community.

In contrast, a $50 million plant being built by foreigners may seem to the locals as yet another isolated project by the colonialists, and therefore a free target for stealing.

I'm not saying your company would act against the local community -- but the locals may not see it that way. To them, a huge foreigner-built project is an extension of what they've seen happen in West Africa ever since the French showed up in the 19th century and started building railroads for their own use.

</comment></comment><comment><USER4> Great article on the NPR about this. [http://www.npr.org/sections/goatsandsoda/2015/07/23/42537654...](http://www.npr.org/sections/goatsandsoda/2015/07/23/425376544/obama- thinks-solar-power-will-boost-kenya-kenyans-arent-so-sure)

</comment><comment><USER5> With a quick superficial read this reminds me of:[http://simpanetworks.com](http://simpanetworks.com) some. It's a really exciting market for social enterprises to get into.

My guy says that decentralized power generation will flourish in the developing world the same way that mobile phones have.

</comment><comment><USER6> Interesting stuff for sure.

The extremely simplistic story is this: connecting to the power grid often costs a few hundred dollars at least, $300 or $400 is common, while annual income is about $1k. Important to note here is that when you have to pay ALL expenses (housing, food, education, healthcare etc) on less than $100 per month, your discretionary income is close to 0, so having to spend 40% of your annual bill to get connected to the grid is a gigantic deal, and can't be compared to spending 40% of say a $50k salary, because $30k of that is discretionary and non-essential for subsistence.

Alright so the grid is there, connecting is expensive, and African nations don't have the rapid economic growth, cheap credit lines or reserve currency status to subsidise it much (like say the US when it connected its rural areas to the grid). And that's a real shame, Kenya's grids aren't great (as few are, on this planet), but there's some real gems here and there. Like Kenya's 1/3rd of electricity coming from hydro, and another 1/3rd coming from geothermal, roughly. Interesting stuff!

Anyway so what happens is that most people have no electricity, do not run e.g. a fridge, but do run small appliances like mobile phones and get them charged in the city. The big expense is lighting, and it's mostly candle or kerosene based.

So for the extremely simple numbers: a kerosine lamp uses about 0.025 - 0.030 litres of fuel per hour, and a litre costs about 60 cents. So running a lamp for an hour is about 1.5 cent. And it generates about 40 lumens or so of light, I mean it really depends but this would be a pretty typical lamp. So you can get with a standard LED easily 80 lumens per watt, so you could essentially get the same light as a kerosene lamp with half a watt. Considering a 15c per kwh price, an hour of powering not one, but two kerosene equivalent LED lightbulbs is two orders of magnitude (100x) cheaper than the 1.5c, as it costs just 0.015c.

Now obviously there's upfront cost in the solar panel, the lightbulb, the battery, and there are per-hour costs too (as bulbs have a lifespan in hours, and batteries in cycles, and panels in years), but the upfront costs are covered fairly quickly (after all you don't need an expensive panel to power a 1 watt lightbulb), the bulb does cost like $10 but here's the thing, lower income households routinely spend $100 or $150 or sometimes more on kerosene per year.

What I don't entirely get is why such a 'decentralised utility company' is necessary. They offer solar as a service essentially, replace batteries, do the 'installation'. But really it's not a solar installation that's necessary, it's just a solar lamp. I don't fully see why there isn't a market for those that has completely replaced kerosene and solved the issue of lighting. Of course solving energy as a whole is a much bigger deal (to move forward you need a connection to the grid, even if it's a local decentralised grid, to run a fridge or tv or business tools etc, outside of the big cities, too). But really, solar lamps are low-tech, no installation required, you buy em and they work. Anyway no disrespect to the company, I'm just wondering why the situation is such that it didn't happen long ago already without any companies other than some wholesalers importing decent solar lamps and flooding the market. These things cost $18. I mean, the financialisation aspect is nice if discretionary income is low, they pay a monthly bill instead of pay $25 upfront, but still $25 is far from insurmountable, I'd have assumed if I started a company like this I'd go to villages to sell and find everyone already has one you know?

<comment><USER7> I think people are already working on the solar lamp thing[1][2][3]. I guess Oola is looking to move beyond that? It sounds like they are hoping to combine it with their mobile payment solution, so maybe the payment platform is _actually_ the play?

[1] [https://www.lightingafrica.org/](https://www.lightingafrica.org/)

[2] [http://www.solar-aid.org/](http://www.solar-aid.org/)

[3] [http://www.dlight.com/](http://www.dlight.com/)

<comment><USER6> Maybe but it looks like the payment platform is done by another company. It's like Uber trying to run an innovative transport company while really just pushing Apple Pay, I think it's unlikely unless there's a strong ownership link between the companies which is certainly possible.

Because again the point of a $20 solar lamp really is that there are no monthly payments like kerosene lamps. How to drive a payments platform on that I still don't really know.

</comment></comment></comment><comment><USER8> How will you prevent your solar systems from getting stolen? Africa has a terrible problem with payment responsibility, and solar cell panels have a unique tendency in Africa of dissapearing.

<comment><USER8> Good luck none the less, I am sure they identified it as a risk.

\- edit Bad spelling, early morning before my coffee.</comment></comment>


Jeri Ellsworth and the Robot Uprising of 2038 - <AUTHOR> http://blog.robertelder.org/jeri-ellsworth-robot-uprising/ <comment><USER2> "Well, magnetic core memory is the only data storage format that is robust enough to withstand high-radiation environments. Jeri is clearly interested in magnetic logic and memory because it is the only computing platform that will be able to survive the first wave of nuclear blasts that will unavoidably come from the beginning of the third great world war. "

Erm, this premise is factually untrue though. A lot of next generation resistive RAM devices, especially OxRAMs, have been demonstrated to be rather rad hard, making them good candidates for future space electronics platforms or.. all the other attendant apocalyptic scenarios.

<comment><USER3> Radiation hardness is different than sensitivity to EMP. It is the eddy currents from an EMPT that build up in and burn out small traces in micro electronics.

<comment><USER4> But magnetic cores are resistant to the M in EMP?

<comment><USER5> I'll offer a wild guess - perhaps they are only temporarily affected (i.e. mem-wiped) and function as normal after device reset, being made of iron, in contrast to semiconductor doping materials being hard-killed by the emp.

</comment></comment></comment></comment><comment><USER6> I have not read the article, but I find the choice of date interesting. 2038 is unix rollover time [1]. It does not appear to be mentioned in the article so it might be a coincidence.

[1]: [https://en.m.wikipedia.org/wiki/Year_2038_problem](https://en.m.wikipedia.org/wiki/Year_2038_problem)

\---Edit---

> but the meek will inherit the earth when judgement day begins on the 19th of > January 2038 at 03:14:07 UTC.

I stand corrected, Unix rollover time is exactly why this date was chosen. It must have broken AI safety protocols in the robots which turned them into killing machines. Cool, I will read this article tonight.

</comment><comment><USER7> Wow that was... Extremely weird. Is this supposed to be some kind of tribute?

<comment><USER8> Weird article. Author isn't technical enough to get how Jeri thinks. I've met her. She sees the physical world in terms of first principles, like Feynman. She built a short range radar from a satellite downlink dish by turning one of the transistors around. I would never have thought you could use a transistor from a low-noise amp to produce enough power to emit a usable signal. I'd be thinking "small-signal transistor" vs "power transistor". But it's an amp, it's got gain, it's fast enough, and she made it work.

<comment><USER9> If you like learning about low power or messy signal stuff, there's some research at UW several years back about using e.g. a combination of em interference from human bodies and normal house electrical wiring/lightbulbs as motion detectors.

That sort of stuff is really cool, and I'm very impressed by people like Jeri who can actually make it work.

</comment></comment></comment><comment><USER10> FYI: [https://en.m.wikipedia.org/wiki/Jeri_Ellsworth](https://en.m.wikipedia.org/wiki/Jeri_Ellsworth)

There is a youtube talk linked in the articles references which is ... just watch it. I am always amazed by these stories - especially as I tried the opening a store in mid nineties flogging computers and internet cafes.

</comment><comment><USER11> I for one really liked that Blade Runner reference with the repetition of "interlinked". My initial vision of the post's future was of The Terminator, but that reference made me consider a more interesting future with different kinds of artificial beings.

</comment><comment><USER5> What makes core memory resistant to EMP?

Wouldn't the pulse change the polarizations stored in the iron cores?

> The highly irradiated port-war landscape will be unable to make use of > standard silicon computer memory for centuries to come.

So we really couldn't use any silicon that was hit to make new semiconductors?

<comment><USER12> The author's argument is that a highly irradiated landscape would be too energetic for silicon based memory to work as it's now designed. I'm not an EE but I've spoken with some engineers of early silicon systems which had to account for high energy cosmic rays flipping the bits within RAM in a random fashion. My guess is that using a solution like Hamming codes would not work when retrieving arbitrary data at a large scale.

<comment><USER13> Off topic, but with smaller lithography, ANY subatomic particle of sufficient energy becomes a problem: [https://www.xilinx.com/support/documentation/white_papers/wp...](https://www.xilinx.com/support/documentation/white_papers/wp208.pdf)

I've spent months chasing random crashes on another vendor's device which turned out to be solder ball alpha emission issues.

</comment></comment></comment><comment><USER14> "My dad had bought me a 101 electronics kit from radio shack..."

Proud to say I had the same kit. Santa is _the man_.

</comment><comment><USER15> >"I ended up dropping out of high school when I was racing cars because I was making so much money."[3] "I started seeing how far I could push the rules. One of the things I built was a traction control system for my race car. I built a single-board 6502 computer (wire-wrap) and I measured the front-wheel spin by putting a hall sensor on it, and I measured the engine RPM." "I had a rev limiter in the car and it would just tell the rev limiter you're over- revving if the back tires were spinning more than the front tires." "Then, I started dominating, just completely dominating.

Sounds a lot like cheating......disruption

<comment><USER16> Finding loopholes or under-specified gray areas in rules to gain an advantage is the secondary activity, besides actually racing, in almost all motorsports.

</comment></comment><comment><USER17> Crazy genius. This is an example of someone born to do something.

<comment><USER18> I know that's just supposed to be a complement, but sometimes that kind of a comment contributes to people thinking there's such a thing as a "math person" (or a "non math person"). Having comments like that thrown around in the aether makes it seem like technical subjects have "you either have it or you don't" characteristics, which I think most people on HN know is BS. I prefer to emphasize hard work over any kind of genetic advantage.

<comment><USER19> My experience is that "you either have it or you don't" is more accurate than not.

> I'm pretty good at what I do, and when people tell me they're jealous of my > talent, and kind of hint that it's innate, I get a bit insulted. I had to > work a shitton to get where I am, and comments like that makes it sound like > I had it easy.

This is a common sentiment, but I don't find it convincing. The discussion here is about nature vs. nurture. There's a lot of data points on that subject, and, from what I've seen, they mostly support nature (twin studies, intelligence being 60-80% heritable, etc).

The fact that you _like to think it 's mostly nurture_ isn't really relevant. I'd _like_ to live in a world where ability and virtue were absolutely correlated and everyone got what he or she deserves based on how much good that person does in the world. But I don't think we live in that world.

<comment><USER20> >My experience is that "you either have it or you don't" is more accurate than not.

Maybe that's correct, but is it more useful than the nurture view?

It's a debate; I mean, clearly, you don't want to spend a lot of time trying to get better at things you will never get better at, but sometimes it's not easy to tell you will be good at a thing until you spend a lot of time on prerequisites.

This is the argument that even if it's true that nature is more important than nurture, it is sometimes more useful to believe that nurture is more important, and that you can learn things.

I think there are a fair number of studies showing that people with a 'growth mindset' as they say, who believe it's about hard work and not just innate ability, tend to do better than people who believe it's fixed.[1]

I mean, in the usual case, of course, people who are smarter are more likely to think than anyone can learn things, 'cause their experience is that learning things is easier, and the way work and education is segmented, quite often people are put near others of their ability. but... I think a lot of these studies control for that.

[1][https://news.stanford.edu/news/2007/february7/dweck-020707.h...](https://news.stanford.edu/news/2007/february7/dweck-020707.html)

<comment><USER20> My own personal view is that some attributes are mostly fixed, and some are not, and it's pretty hard to tell which is which.

Sometimes you need to struggle for a long time through stuff you aren't any good at to get to something you are good at. I love reading and read very quickly, with above average, but less impressive compared to speed, comprehension.

But it took me longer than usual to learn to read. I assume because I'm terrible at memorization; and to learn to read, you need to memorize enough words that you can start puzzling out the words you don't know from context. I would not have done well if I had given up on reading because I was inherently bad at one of the prerequisites.

On the other hand, I spent a lot of time trying to run a business... and that turned out to be something I didn't get good at after a decade of trying; so yeah, sometimes it's best to give up early, but it can be really hard to predict which side of that equation a particular problem is on.

<comment><USER20> A better comparison to reading is writing. My handwriting is terrible. Like not doctor-terrible; there's at least dignity in that. It's a grade-schooler's block letters. It's terrible. And I spent so much wasted time and effort on it.

I mean, I've had access to a computer since the mid-80s, so I could write, I just couldn't hand write. And it turns out? nobody cares about my handwriting anymore. It's not that useful when you have portable computers. (In the mid '90s I took a tandy TRS-80 model 100 to high school. Such a nice keyboard)

I argued and fought with my parents who made me practice handwriting, arguing even in the early '90s that it was an obsolete skill; but they sat with me for hours a day, making me copy letters. Just like they did earlier, when they were making me learn how to read.

But reading, well, it went from a struggle to make me practice to the thing I got in trouble for doing when I was supposed to be doing other things almost overnight. It was like I finally memorized enough of the words to figure out young adult fiction, and a whole new world opened up to me.

Handwriting never got to that point, even though there was a lot more struggle involved. To this day, I can't write coherently with a pencil and paper for more than a sentence or two; it takes too much focus to make the letters, and the thoughts about the sentence or paragraph evaporate.

How much of this is my own motivation? I do remember arguing that handwriting was useless 'cause I could type, and that was better. If I had access to a state of the art screen reader (they existed at the time, and I think were okay?) I maybe would have made the same arguments about reading. Would that have made it harder for me to actually learn to read?

</comment></comment></comment></comment></comment></comment><comment><USER21> I found a new person to follow! From this blogpost and her wikipedia page I'm impressed.

I wonder though -- is the fear of the Robot Uprising of 2038 founded, to her, or is that applied drama by the blog author?

<comment><USER22> I don't know her personally, but I've followed her for a while and I've never heard her mention anything of the sort. Also, the author didn't mention anything about her work with augmented reality, I guess it didn't fit the narrative. To be fair though, I only read the first 1/4 and skimmed the rest b/c I couldn't stand the robot uprising slant. Can't she just like cool old tech without being a cyberpunk pepper?

If you're interested, she has done some excellent interviews on the amp hour podcast. The episode referencing her semiconductor making experiments: [https://theamphour.com/the-amp-hour-52-carnassial-chip- chemi...](https://theamphour.com/the-amp-hour-52-carnassial-chip-chemicals/) All episodes: [https://theamphour.com/?s=jeri](https://theamphour.com/?s=jeri)

(edit: copy/paste error)

</comment></comment><comment><USER23> Highly recommend Jeri's youtube channel

</comment><comment><USER24> I have a bit more positive look on the future: Jan-2038 is just before my retirement. I can make some money with old computer knowledge while the post- post millennial generation does not even know what the inside of an old operating system looks like.

<comment><USER5> Your old computer knowledge will be about the same worth as what income that can be generated today having extensive knowledge of Multi-User Dungeon forum software.

<comment><USER25> MUDs were advanced data processing systems. As a kid I wrapped my head around one with a 100k line code base. That has led to quite a successful career and I still use a lot of the same techniques I learned.

<comment><USER5> That's cool, yeah. Must've seen some interesting coding practices in that code base

<comment><USER25> [https://github.com/smaugmuds/_smaug_/tree/master/src](https://github.com/smaugmuds/_smaug_/tree/master/src)

I still do C so it isn't so far removed.

</comment></comment></comment></comment></comment><comment><USER26> brilliant,

but for

>Triboluminescence with household chemicals - Keep your eye on what happens when the battery falls over in this video.

I watched it over a couple of times, but never actually catch the battery fall over, the subject matter is constantlly grabbing my attention. at what time does it fall over?

</comment><comment><USER27> But now that she's on the internet the robots will know to find her after the uprising.

<comment><USER28> Jeri likely would find a way to defeat the robots by building a machine gun that shoots pinballs and is controlled by a brainwave interface to a SID chip.

</comment></comment><comment><USER25> Catch 22. The killer robots will be quite proficient in tracking electromagnetic radiation.

</comment><comment><USER29> The robot uprising will begin and I predict the battle turns at 12am Jan 1st, UTC, as the 32 bit system clocks overflow in many of the small micros controlling subsystems.

</comment><comment><USER30> starts with a typo

</comment><comment><USER5> > Jeri Ellsworth _hates_ this article

probably used in jest - but playing along - probably because premise of article is heavy on summoning up ethos & pathos to generate interest whereas, from what I can tell of Jeri's style, she is more centered on direct logos.

in a way, the way OP uses ethos/pathos method is somewhat deceptive/dishonest, because it's trying to get you interested in source material for reasons that are entirely make-believe.</comment>


Ask HN: Best way to get started with Android Development? - <AUTHOR>

The language I know the best is Python, but I am not afraid to use something else. Instead, I am more concerned about having to install a virtual Android device on my computer and other pains like that.<p>What would you recommend? <comment><USER2> Ever considered this ? [http://kivy.org/#home](http://kivy.org/#home)

<comment><AUTHOR> That looks great, thank you! Did you use it personally? What are your thoughts about Kivy?</comment></comment>


Scalene: a high-performance, high-precision CPU and memory profiler for Python - <AUTHOR> https://github.com/emeryberger/scalene <comment><USER6> Sadly, relying on Python's signal handling is not enough to get robust profiling information the moment your code is spending a significant chunk of time outside of simple Python calls. This is because signals don't get delivered to the Python level until the interpreter comes back from C land, and it's possible to get stuck in C land even with pure Python code.

To wit:

      $ python -m scalene trace.py
      f1 1.3852 312499987500000
      f2 1.2420 2812499962500000
      f3 1.5018 1.5
      trace.py: % of CPU time =  33.66% out of   4.13s.
      Line  | CPU %    |  [trace.py]
         1  |          | #!/usr/bin/env python
         2  |          |
         3  |          | import time
         4  |          |
         5  |          | def timed(f):
         6  |          |     def f_timed(*args, **kwargs):
         7  |          |         t = time.time()
         8  |          |         r = f(*args, **kwargs)
         9  |          |         t = time.time() - <USER5>
        10  |          |         print('%s %.4f %s' % (f.__name__, t, r))
        11  |          |     return f_timed
        12  |          |
        13  |          | @timed
        14  |          | def f1(n):
        15  |          |     s = 0
        16  |  17.99%  |     for i in range(n):
        17  |  81.29%  |         s += i
        18  |          |     return s
        19  |          |
        20  |          | @timed
        21  |          | def f2(n):
        22  |   0.72%  |     return sum(range(n))
        23  |          |
        24  |          | @timed
        25  |          | def f3(t):
        26  |          |     time.sleep(t)
        27  |          |     return t
        28  |          |
        29  |          | if __name__ == '__main__':
        30  |          |     f1(25_000_000)
        31  |          |     f2(75_000_000)
        32  |          |     f3(1.5)

<comment><USER7> Good observation. My personal POV is that the best way to optimize your Python code is to use native code (whether as libraries or through pure Python code that is essentially a thin wrapper over C) rather than living in the interpreter. I want to see the parts of the program that are spending that time in the interpreter.

In short, a profiler that tells me that a program is spending a lot of time in C is not generally providing me particularly actionable information.

(In any event, the top-line report is that the Python part of the program only accounts for 33.66% of the execution time, which looks just about right.)

<comment><USER6> I can understand this approach, but I fundamentally disagree with it - <USER3> first duty of a profiling tool is _not to mislead the user_.

In this example, the program spends a third of the time just sleeping / blocked, a third of the time on CPU but at the C level, and the remainder just evaluating Python loops. Unless you already know how it's implemented, that 33.66% is not easy to interpret, and the docs don't mention what _exactly_ is being profiled. Specifically, these samples aren't a % of CPU time, they're a % of real time that we happened to have been able to do a Python-level interrupt, and even that isn't a great explanation. I think most users would still expect line 22 to get traced properly.

I very much _do_ want to know about C time, too, because it's very much actionable for most of the optimizations I end up making in production systems.

That said, I don't think this line of discussion is super productive for either of us, we seem to have different goals in mind, which is fine. ;)

So I'll close by saying that I was impressed by your LD_PRELOAD hacks for memory profiling, which isn't an approach that I've ever seen in other Python profilers.

<comment><USER7> Re: being impressed by the memory profiling hacks, thanks! :)

And you persuaded me. New version to be uploaded momentarily that attributes time to line 22.

      % python3 -m scalene sample-sample.py
      f1 1.8081 312499987500000
      f2 1.7910 2812499962500000
      f3 1.5034 1.5
      sample-sample.py: % of CPU time =  70.53% out of   5.10s.
        Line  | CPU %    |  [sample-sample.py]
           1  |          | #!/usr/bin/env python
           2  |          |
           3  |          | import time
           4  |          |
           5  |          | def timed(f):
           6  |          |     def f_timed(*args, **kwargs):
           7  |          |         t = time.time()
           8  |          |         r = f(*args, **kwargs)
           9  |   0.32%  |         t = time.time() - <USER5>
          10  |          |         print('%s %.4f %s' % (f.__name__, t, r))
          11  |          |     return f_timed
          12  |          |
          13  |          | @timed
          14  |          | def f1(n):
          15  |          |     s = 0
          16  |   8.58%  |     for i in range(n):
          17  |  41.34%  |         s += i
          18  |          |     return s
          19  |          |
          20  |          | @timed
          21  |          | def f2(n):
          22  |  49.76%  |     return sum(range(n))
          23  |          |
          24  |          | @timed
          25  |          | def f3(t):
          26  |          |     time.sleep(t)
          27  |          |     return t
          28  |          |
          29  |          | if __name__ == '__main__':
          30  |          |     f1(25000000)
          31  |          |     f2(75000000)
          32  |          |     f3(1.5)

<comment><USER7> This discussion inspired me to refine Scalene's output further. Scalene now separates out CPU time spent in Python from time spent in C (that is, not executing in the interpreter). I think this is the best of both worlds: all CPU time is accounted for, and it's easy for users to see what code is running where. Thanks!

      sample-sample.py: % of CPU time =  99.58% out of   3.34s.
               | CPU %    | CPU %    |
        Line   | (Python) | (C)      | [sample-sample.py]
      </comment></comment></comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>--
           1   |          |          | #!/usr/bin/env python
           2   |          |          |
           3   |          |          | import time
           4   |          |          |
           5   |          |          | def timed(f):
           6   |          |          |     def f_timed(*args, **kwargs):
           7   |          |          |         t = time.time()
           8   |          |          |         r = f(*args, **kwargs)
           9   |          |          |         t = time.time() - <USER5>
          10   |          |          |         print('%s %.4f %s' % (f.__name__, t, r))
          11   |          |          |     return f_timed
          12   |          |          |
          13   |          |          | @timed
          14   |          |          | def f1(n):
          15   |          |          |     s = 0
          16   |   6.61%  |   0.41%  |     for i in range(n):
          17   |  35.17%  |   3.97%  |         s += i
          18   |          |          |     return s
          19   |          |          |
          20   |          |          | @timed
          21   |          |          | def f2(n):
          22   |   0.30%  |  53.53%  |     return sum(range(n))
          23   |          |          |
          24   |          |          | @timed
          25   |          |          | def f3(t):
          26   |          |          |     time.sleep(t)
          27   |          |          |     return t
          28   |          |          |
          29   |          |          | if __name__ == '__main__':
          30   |          |          |     f1(25000000)
          31   |          |          |     f2(75000000)
          32   |          |          |     f3(1.5)

<comment><USER8> Just wanted to take a moment to appreciate the awesome response to feedback and new added feature.

<comment><USER9> Yeah, love this kind of discussion and interaction on hnews!

<comment><USER10> Yeah this is some of the best HN back and forth I've seen!

Kudos to everyone involved.

</comment></comment></comment></comment><comment><USER11> I love the idea of fast Python profilers that don't require modified source code to run.

One profiler I used recently which isn't mentioned in the readme is pyflame (developed at uber):

[https://pyflame.readthedocs.io/](https://pyflame.readthedocs.io/)

pyflame likewise claims to run on unmodified source code and be fast enough to run in production, so it might be worth adding to the comparison. It generates flamegraphs, which greatly sped up debugging the other day when I needed to figure out why something was slow somewhere in a Django request-response callstack.

<comment><USER12> Similar to PyFlame is also py-spy: [https://github.com/benfred/py- spy](https://github.com/benfred/py-spy)

> While pyflame is a great project, it doesn't support Python 3.7 yet and > doesn't work on OSX, Windows or FreeBSD.

I wonder how the CPU profiling in Scalene is different. It does not mention PyFlame or py-spy at all in the Readme. Of course, the memory profiler is some nice extra.

<comment><USER7> Scalene author here. I was not aware of either tool - many thanks for the pointers! I just tried py-spy (I will try PyFlame on a Linux box momentarily). It's pretty cool, though having to run it as root on OS X isn't great (scalene runs without the need for root privileges; the CPU profiling part is pure Python). Py-spy does appear to efficiently track CPU perf at the line granularity (and does a lot of other stuff). It does a lot of things that scalene does not do, but not memory profiling. Also, I personally prefer scalene's line-level display of annotated source code vs. the flame graphs, but YMMV.

<comment><USER13> The possibility to run py-spy on an already running Python program in production is pretty awesome. Do you think Scalene could do this?

</comment></comment></comment></comment><comment><USER14> Another python profile that isn't mentioned is pprofile[0]. It is also a statistical profiler with line-level granularity. It doesn't have the memory profiling abilities (that is pretty slick...), but it also doesn't require the dynamic library injection.

I don't know how it's statistical profiling speed compares to scalene, but it would be great to see the comparison.

Also, does anyone know how the malloc interacts with pytorch?

[0][https://github.com/vpelletier/pprofile](https://github.com/vpelletier/pprofile)

</comment><comment><USER15> Another similar sampling profiler which has decent performance is pyinstrument: [https://github.com/joerick/pyinstrument](https://github.com/joerick/pyinstrument)</comment>


Copmpeting IMDB – any chance? - <AUTHOR> http://www.viptrace.com

<comment><AUTHOR> Viptrace.com is modern content tracker and a full, self-renewed visual database of all movies, books and music releases with an instant access to content via apple, amazon etc. Users build their feeds from content sources by "tracing" them with. We think we are nicer and easier to navigate than IMDB, and what do you think?</comment>


Ask HN: Is it "bad" to use Themeforest? - <AUTHOR>

I am a developer and I can't design for shit. So, I tend to use Themeforest themes for my personal projects and stuff.
I had an idea for a site which I think could be really useful and could gain traction - would it be "unprofessional" to use a Themeforest theme?
I fund all of my projects from my pocket and have maybe $50 which I can use - I can't afford to hire a designer.
Thanks in advance. <comment><USER2> It is not "unprofessional" to use a ThemeForest theme.

What does that even _mean_ , really? Break it down.

Do you think customers will not buy if you use a ThemeForest theme or Twitter bootstrap or WooThemes or what have you? If so, empirically denied: I've sold hundreds of thousands of dollars of product on sites using those options personally, and many people have had that experience.

Do you think you owe it to the universe to hire a designer? I don't know why you'd think that, but some people apparently do, so let's time-shift that owning-designers-money thing into the future, just like designers have apparently timed-shifted giving-you-more-than-$50-for-your-programming services into the future.

Do you think "professional" sites necessarily have awesome, jawdropping unique design? That is not true and would not withstand scrutiny through the WayBack machine. The biggest Internet companies you can think of all launch withed worse than what $5 will buy you on ThemeForest. Some of them are still there ( _cough_ Craigslist).

<comment><AUTHOR> No, I'm perfectly fine with Twitter Bootstrap and similar because its highly customizable and after a few hours coding, it won't even be recognizable.

I'm using an Admin template for a web app and its pretty unique.

I just don't want to be "mocked" because I didn't take the time and money to make a more unique interface. Like North Korea was mocked because the Democratic People's Republic of Korea's site (<http://korea-dpr.com>) cost $15 because they bought a template of Themeforest.

I know it shouldn't be a really big problem, but I'm second guessing every decision I've made because I'm really nervous about this one. (I've switched between PHP and Python and Linode and Heroku about 15 times now).

<comment><USER3> Being mocked is a badge of honor. It means you have the hustle to ship and get things out in front of people. You should worry a little bit if you're _not_ being mocked. Maybe you're that good, but, really, for the most part, the people who mock new businesses the most tend to be too dumb to tell the difference. So, not being mocked probably means you're wasting time being too vain to ship.

Forget the web design stuff. Use Themeforest, or the Boostrap _defaults_ , and spend your time getting your product to do things people will pay money for.

<comment><AUTHOR> Thanks! I'm learning to see quite a few things in different ways today. :)

</comment></comment></comment></comment><comment><USER4> I'm a designer, so let me flip your question another way:

Is it bad for a designer to use a stock photo if they can't afford a photographer?

Of course not! Will the design look a bit generic? Yes it will. But that's not a big sin in the larger scheme of things if you have a low budget project. Design is about problem solving as much as it is about creativity.

However I will say the following: Just like selecting "off the rack clothing" use care in picking a theme that best matches your project. In fact for an extra $50 you could even get a designer to help you pick something that best matches the project.

<comment><AUTHOR> Interesting view... Difference is that a stock photo is just one part of a bigger picture (as you said). However, a theme is everything that the users sees, not just a part.

I'm using Pastel and it seems perfect for the project.

Thanks for the input, it helped.

<comment><USER4> Actually with many designs (and this really print) the photo could be the main center of attention. In fact a custom photo should communicate the concept of the design, not just illustrate it. So just think of the difference between say a cover photo on a magazine (like an Entertainment Weekly issue with a real Hollywood Star) vs. the generic stock photo. So the photo should be everything -- and the same with the interface and art direction of a website.

<comment><AUTHOR> I never thought about that... Perhaps I need to take some design courses :D

<comment><USER4> Forget design -- take an art history course! that's the foundation...

</comment></comment></comment></comment></comment><comment><USER5> Where your theme comes from isn't going to concern 99.9999% of your audience and most wouldn't be able to tell the difference between and handcoded theme and one bought off themeforest. It's more important to get the project out, you can always iterate over the design later.

<comment><AUTHOR> Makes sense. If it becomes popular and I make some money, I could use that to give it a facelift. :D</comment></comment>