I have to say that I completely disagree with this perspective. Yes, currently our 'lingua franca' of business and technology is English, but I feel that is a problem, not a solution.
It's a problem because it unfairly advantages native English speaking people in business. It creates a barrier of entry to people who did not learn English from an early age, along with their native language. It makes it much harder for those people to be part of business, technology, and open source. It degrades the quality of communication and work-output by forcing non-native speakers to express themselves in English.
Does being a good engineer imply being good at spoken natural languages? I have met some brilliant engineers in China who are barely functional in English. If you were to interact with them purely in English, you would think you're talking to a 5 year old, based on the language alone. Some of the engineers I've met in China aren't even that capable with English, but are wonderful developers writing interesting things.
Sometimes they created documentation in Chinese, sometimes in English. Guess which one they were able to express their ideas in more clearly? Chinese.
When you write, you should write in your native language, and express your idea to the best of your ability. Then, if you want to translate that to other languages later, to make it more accessible to others, do that as a separate task. Maybe hire a professional technical translator to do that work.
You gave this example of coming across a page written in Lithuanian or Japanese, presuming of course that you're not a native speaker of those languages. Fine, that's exactly how every Chinese native speaker feels when they come across a page of English text, every day of their life as a developer... but they figure it out, even with terrible language skills. You know why? Not because "English is the language of business" but because they just want to learn about the content, and aren't going to try to force you to write it in Chinese so they can do that. If all those pages were in French they would figure that out too.
With the attitude you expressed above, the main people who benefit from this are native English speakers. Anyone else is still in the 2nd language boat. So then of that group, you advantage people with a talent for natural languages, or who are wealthy enough, as a child, to have access to education resources to learn another language. As a former English teacher in China, I promise you that this is a huge economic divide. The kids who can afford to learn English succeed, those who can't, don't. That's fucked up, and not at all a reasonable way to approach business. A good engineer should not be left with no opportunities because they grew up poor, or have no real talent learning foreign languages.
In business, such concerns about equality and fair access might not be very important, because unfair advantages and competition are what much of business is all about... but in open source, and in modern businesses that are learning from the open source model, I think being concerned with inclusiveness is paramount. So yes, you might have to struggle through reading something like this:
... but it doesn't take much to punch "Youki 是一个文档生成语言，其具备完整的编程特性和完备的宏特性，使之可作任意复杂的文章。Youki 是完全开放源码的，依照 MIT 协议发布。" into Google Translate (or use the auto-translate features of Chrome). Now we can all get on with our lives and use be5invis's cool documentation generation tool.
Would you prefer to exclude him and his work from our community by forcing him, a Chinese square-peg through some English speaking round-hole? Personally, I'm willing to do a little extra work to understand him in his own language. I also appreciate deeply that he has to do that work constantly, in order to read my code/docs in my native language.
Most people in the world do not speak one of the uber-languages (english, chinese, spanish etc). These people are particularly poorly served by a drive to document in their native language rather than a common language. If someone only speaks Xhosa and never gets to exercise a documentation-common-language, then they'll only be able to read and contribute to documentation in Xhosa, which is a much smaller community than 'everyone'. And what if the leading engineer in your field didn't document in that language? You'd be cut of from what they had to say.
A common documentation language functions as a technical standard, like IPv4. Sure, you can use your own standard, perhaps IPX, but you'll only be able to communicate with a much smaller group of people.
It's hard to get documentation written in the first place, let alone good documentation. Making it 'fair' by saying that documentation has to be effectively splintered into every native language is a sisyphean task.
As always, write to your audience. If it's a general tech audience, that means English. If it's Chinese engineers who don't speak English well, that means Chinese. But those Chinese engineers are going to have an easier time interpreting foreign documentation if it's all in one language rather than 50.
I don't disagree. The problem of standards is that sometimes they help and sometimes they hurt. They always seem like a great solution, but rarely are.
Wouldn't it be nice if we all spoke the same language?
So much less conflict, so much more efficient.
Wouldn't it be nice if we all had the same cultural background?
So much less conflict, so much more efficient.
Wouldn't it be nice if we all looked and acted exactly the same?
So much less conflict, so much more efficient.
Wouldn't the world be a nicer place without all this pesky diversity?
So much less conflict, so much more efficient.
In the end, there's not one correct answer. The point of documentation is communication. Communication is a very malleable thing. It is negotiated on demand and the form of it varies a lot. The real beauty of many of our underlying systems is their ability to negotiate a protocol, not the pervasive standard use of a single protocol.
A couple personal stories:
Once, I was in Switzerland, and went to a Chinese restaurant. The waitress spoken Cantonese (1st), Swiss (2nd), and Mandarin (2nd). I spoke English (1st), German (2nd), and Mandarin (2nd). We quickly figured out that we could communicate most effectively in Mandarin, and so we did.
Later on in that trip, I went to an Italian restaurant. The owner spoke Italian and some very limited Swiss, but no English. I couldn't speak Italian or Swiss enough to communicate with him. Instead, we used gestures, body language, and pictures. It worked out, and I got one of the best plates of lasagna I've ever had.
The message here is that language is not standardized, and will never be, so calling English a standard is just a failure of reason. It's a sub-par medium for communication for the majority of the world.
You never know who is going to walk in the door of your restaurant to order food. Do your best to communicate with them, without too many assumptions, and you'll find that communication can be negotiated easily.
That said, in more practical terms, I actually encourage the use of less text, but more pictures, examples, and tactile learning approaches in documentation. When text is required, it should be "High Fidelity" and that means, written in the native language of the person writing it. Then, you have the ability to degrade fidelity later, by translating it to whatever language you've negotiated for when the native language doesn't match.
I agree that language is not standardized and should never be.
I see English in programming as the somewhat lowest common denominator. At least in the "western world".
From all the 4 languages I learned and some more I messed around with, English was the easiest to get to a basic level. On Par with Spanish. This is highly biased of course.
Although my mother tongue is German(Swiss), I usually avoid documentations, tutorials, etc in German for multiple reasons.
- The mix of english terminology, germanized terminology and normal German makes it hard to read.
- They are mostly just translated and not rewritten, which sometimes leads to some strange formulations.
- I'm forgiving/ignorant for grammatical errors in foreign languages
- They tend to be outdated.
I agree that documentation should only use as few text as possible and as much necessary. Editable and runnable examples are the best way in my opinion. Also, no matter what language, documentation should be written using simple words, short sentences and not try to win a pulitzer prize.
I don't mind documentation in English. What really pisses me off is, when I have to work with software where the developers/designers clearly didn't account for things like letters with stuff on it (éàüöøñ…), variable sentence lengths, date formats, etc.
It's a sub-par medium for communication for the majority of the world.
However it's currently the best universal medium we have, and you're arguing to actively remove that, rather than replace it with a system that improves global communication.
Not to mention "can I have one of these items of food that you prepared" is a much easier concept to convey than technical information, which can get quite nuanced. Figuring out how to analyse a stack trace is not something you can do with body language. And body language isn't universal, either.
Yes, language is not standardised, but we're talking about language for a specific purpose here, not language in general. Don't get me wrong. I like to be around a variety of languages, though I'm a monoglot. But I don't see the point in trying to remove an extant common language out of a philosophical sense of fairness, when it would actually decrease communication between people.
Wouldn't the world be a nicer place without all this pesky diversity?
The slippery slope you're painting here doesn't exist. Having a common language is not the same as turning everyone into WASPs and doesn't lead to it, any more than speaking Spanish means that Mexicans, Peruvians, and Spaniards are the same culturally. Or speaking French meaning that the French, Algerians (half of...), and Quebecois are the same culturally.
Ok. Now I am genuinely curious. Could you point me to projects/code samples from this person?
I have never come across a situation such as you described and I am very curious to see proof positive of someone phenomenally bad at English and phenomenally great at programming. Please, help expand my horizon!
For the record, I am a non-native English speaker.
What's humorous is that many apps are just HTML5 webpages loaded in a "app" frame, so there's very very little difference.
That said, in the case of a Bitcoin wallet, Coinpunk is unique because it's implementation is primarily in client-side Javascript. Most of the wallet services either rely on server-side crypto, or native apps.
Because of that technological dependency, either the service controls your data, or the mobile app store controls the distribution of the app.
With Coinpunk, no one can control it. No one. It's yours and always will be.
Regarding the shameless product plug: Quay looks like a very cool product. Love the history and diff views. Glad to see pricing mimics Github model "pay for private, but public is free and unlimited". Awesome!
Regarding complexity in Docker: So here's the thing, people wanted npm, but they got git. How can we bridge the gap between a easy to use, out of your way package manager and a fully featured DVCS experience? I love the idea of merging them, but IMO, need to make the semantic model more accessible. Specifically, need to ensure concepts are properly orthogonal, not overloaded, and unambiguously defined. Might be too late to scrub this aspect though.
Some other general problems are things like checksums, fingerprints, image signing, etc. How to verify the validity of an image?
I will speak to the issues about which I am familiar.
Checksums are currently uploaded by the client and verified by the registry. Signing is on the roadmap[1]. I'm not sure what you mean by a fingerprint, would this be analogous to an SSH host key? What function would it serve if you already had a signature that only you could reproduce?
A fingerprint is just a small, easy to recognize string that identifies a pub key of a trusted individual. It's helpful with recognizing the "trustfulness" of a release. More important than the fingerprint though is the pub key of the release engineer, and a web of trust to verify that key.
The process that is the gold standard for this, IMO, is what's used over at Apache Software Foundation.
For those who aren't familiar with the topic, I'll illustrate with a release I made a few years ago, here's the release artifacts for Lucene.Net 2.9.2:
You'll find a .zip, .asc, .md5, and .sha1 file. The .zip is the release artifact. The MD5 and SHA1 are just two different hashes to prove that the package you got is not corrupt and is what it should be, similar to a checksum (note: these hashes should also be signed, IMO). The .asc is a signature for the release.
A signature is made from the release engineer's key pair and the release artifact. gpg can take the .asc and the .zip as inputs and tell you what pub key made the signature (and it reports it as a short fingerprint). If you've imported a trusted key into gpg, it will tell you that it's a verified and trusted key, and tell you who it was.
If you pull all these files together and verify them, this should be your result:
$ curl -sSL http://people.apache.org/\~thoward/F1AADDE6.asc | gpg --import
gpg: key F1AADDE6: public key "Troy Howard (CODE SIGNING KEY) <thoward@apache.org>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
$ gpg --verify ~/Downloads/Apache-Lucene.Net-2.9.2-incubating.src.zip.asc ~/Downloads/Apache-Lucene.Net-2.9.2-incubating.src.zip
gpg: Signature made Fri Feb 25 09:33:40 2011 PST using RSA key ID F1AADDE6
gpg: Good signature from "Troy Howard (CODE SIGNING KEY) <thoward@apache.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 062B 4DAF 06F8 61CD 2E71 E40B 8EAA A8A8 F1AA DDE6
Anything else, and you should not use the release.
A good package and release system, like Docker Index/Registry should build these verifications in automatically. A tool like Quay can host pub keys, and can automatically sign images. The Docker Index API can be extended slightly to support fetching the signature. Docker itself could be extended to support "verified" mode, where it refuses to run images that don't have a signature, or fail key verification from a trusted set of keys.
BTW: If you're doing beta access, I could use this immediately for http://riakon.com .. Currently using something I hacked together w/ warden, but Docker looks like a more elegant solution (and I'd rather be part of a community than using my own one-off hack).
It's a problem because it unfairly advantages native English speaking people in business. It creates a barrier of entry to people who did not learn English from an early age, along with their native language. It makes it much harder for those people to be part of business, technology, and open source. It degrades the quality of communication and work-output by forcing non-native speakers to express themselves in English.
Does being a good engineer imply being good at spoken natural languages? I have met some brilliant engineers in China who are barely functional in English. If you were to interact with them purely in English, you would think you're talking to a 5 year old, based on the language alone. Some of the engineers I've met in China aren't even that capable with English, but are wonderful developers writing interesting things.
Sometimes they created documentation in Chinese, sometimes in English. Guess which one they were able to express their ideas in more clearly? Chinese.
When you write, you should write in your native language, and express your idea to the best of your ability. Then, if you want to translate that to other languages later, to make it more accessible to others, do that as a separate task. Maybe hire a professional technical translator to do that work.
You gave this example of coming across a page written in Lithuanian or Japanese, presuming of course that you're not a native speaker of those languages. Fine, that's exactly how every Chinese native speaker feels when they come across a page of English text, every day of their life as a developer... but they figure it out, even with terrible language skills. You know why? Not because "English is the language of business" but because they just want to learn about the content, and aren't going to try to force you to write it in Chinese so they can do that. If all those pages were in French they would figure that out too.
With the attitude you expressed above, the main people who benefit from this are native English speakers. Anyone else is still in the 2nd language boat. So then of that group, you advantage people with a talent for natural languages, or who are wealthy enough, as a child, to have access to education resources to learn another language. As a former English teacher in China, I promise you that this is a huge economic divide. The kids who can afford to learn English succeed, those who can't, don't. That's fucked up, and not at all a reasonable way to approach business. A good engineer should not be left with no opportunities because they grew up poor, or have no real talent learning foreign languages.
In business, such concerns about equality and fair access might not be very important, because unfair advantages and competition are what much of business is all about... but in open source, and in modern businesses that are learning from the open source model, I think being concerned with inclusiveness is paramount. So yes, you might have to struggle through reading something like this:
https://github.com/be5invis/youki/blob/master/README.yk
... but it doesn't take much to punch "Youki 是一个文档生成语言，其具备完整的编程特性和完备的宏特性，使之可作任意复杂的文章。Youki 是完全开放源码的，依照 MIT 协议发布。" into Google Translate (or use the auto-translate features of Chrome). Now we can all get on with our lives and use be5invis's cool documentation generation tool.
Would you prefer to exclude him and his work from our community by forcing him, a Chinese square-peg through some English speaking round-hole? Personally, I'm willing to do a little extra work to understand him in his own language. I also appreciate deeply that he has to do that work constantly, in order to read my code/docs in my native language.