Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The table of harmful things and alternatives is fascinating. I'd love to see the rationale for each row.


The hint mentions "complexity is the bane of all software, simplicity is the most important quality"

Seems right for C++ vs C, Go and XML vs JSON, CSV for example.


Yeah, I agree with your examples aside from the ability to validate XML; I'm not a heavy user of json but I don't believe it's possible to tell whether a document is well formed. Anyway, the lack of rational means it doesn't address essential vs accidental complexity. Are the harmful items harmful because they have lots of accidental complexity? Or are the problems they exist as a solution for simply hard problems? If complexity of a harmful entry is mostly essential it would be interesting to know why it was still considered harmful. For instance, Bash is considered harmful but is nice as a user shell compared with say, sh.


> I don't believe it's possible to tell whether a document is well formed.

http://json-schema.org/


Fair enough! I'll keep that in mind :)


Yeah with XML, there was a period there probably late 1990s to early 2000's when it was supposedly the silver bullet that was going to glue disparate software and systems together. When used well its fine, but it was probably over used, especially in things like configuration files where a simple key + value pair text file would have sufficed.


I love that flat files are considered less complex, but SQL DBs are bad.... I would love to know under which criteria that is true for the author. Is it "music I listened to last week"?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: