Rust 1.13 Brings ? Operator, Better Performance

[liam]

That's not a feature. Allowing people to write variable names with umlauts and other garbage like that will make the code unreadable for anyone that isn't of the same nationality of the writer. It's already bad enough that people comment in whatever is their shitty language or dialect and not in english (and I'm not a native english speaker myself).

What's next, allowing the code to be written right-to-left Arab-style? Turning language features in specific ideograms to make Chinese/asian feel more at home?

Madness, madness I say.

You (might?) are joking, but it's not wrong.
Programming languages employ tiny vocabs, and right now, english is the lingua franca for the "educated".
Now, imagine trying to learn a codebase that includes ǃama ʘʔâni
It might be solvable by including markup (generated, or otherwise).


[QUOTE=totoz;n910519]And worse: some developers won't be able to type some specific characters used by others, because it's not on their keyboard, so it will be a pain to make code evolutions.

That's not the issue b/c we've solved that particular problem (for the vast majority of the world's populace).

[starshipeleven]

You (might?) are joking, but it's not wrong.
Programming languages employ tiny vocabs, and right now, english is the lingua franca for the "educated".
Now, imagine trying to learn a codebase that includes ǃama ʘʔâni
It might be solvable by including markup (generated, or otherwise).

Not joking one bit, I've seen code made by random guys from Tunisi commented in their local language, and the only way we managed to understand the fuck was doing that code without hiring an interpreter is because they wrote the variable/method names in french.
I mean, I'm not blaming the guys, but whoever thought it was a good idea to not state CLEARLY that codebase comments should be in english for shared stuff should be shouted at, for the least.

And quite frankly I doubt that bad variable names can be solved in practice (in the sense that they COULD also include markup or better docs, or whatever, but they probably won't).

[liam]

Not joking one bit, I've seen code made by random guys from Tunisi commented in their local language, and the only way we managed to understand the fuck was doing that code without hiring an interpreter is because they wrote the variable/method names in french.
I mean, I'm not blaming the guys, but whoever thought it was a good idea to not state CLEARLY that codebase comments should be in english for shared stuff should be shouted at, for the least.

And quite frankly I doubt that bad variable names can be solved in practice (in the sense that they COULD also include markup or better docs, or whatever, but they probably won't).

Well, I honestly wasn't really considering comments. Sure, we should all be programming in the Literate way (not really, but let's assume), but, quite aside from me knowing of no one who does this, it does rather force the programmer to be rather more proficient in english than I think necessary.
I know this is cliche but good code doesn't need comments**
I don't do this b/c I don't consider myself a good enough coder, and I think it important to document my process (yes, I sort of do program in a vaguely Literate way, but, still, not exactly, and certainly not always).
The variable names problem seemed the only tractable issue until machine translation becomes good enough to handle niche idioms.
Speaking of, that would be an interesting project. A db of good variable names where you are offered a number of multilingual categories (after all, they need someway to actually know what the hell they are looking at BUT I don't think that would actually be completely necessary), with greater specificity within each as needed.
You'd also want to provide some (visual) clues so that they can combine basenames with verbs, but I doubt you'd want to go much further.
It's not perfect, but you'd avoid some of what you experienced, though it wouldn't have helped much in your case.

*in most cases

[starshipeleven]

Well, I honestly wasn't really considering comments. Sure, we should all be programming in the Literate way (not really, but let's assume), but, quite aside from me knowing of no one who does this, it does rather force the programmer to be rather more proficient in english than I think necessary.

If you don't know english you don't have access to Stack Overflow, is that a good enough reason to learn it?

Back serious, even broken english is better than $random_local_language because english is very fault-tolerant, you can write sentences with broken syntax and grammar that are still mostly understandable and much better than Google Translating (especially asian->english).

I know this is cliche but good code doesn't need comments**

I partly disagree. I mean, ok, writing large comments with the whole pseudocode of the project everywhere is bad (would be great for anyone trying to do maintenance on it, though), but a generic explanation of what each class does at the top (talking of java, C++ has .h files for that), or what each more complex passage is supposed to do is useful for sharing the code (and for you if you forget things).
Also size matters, and type of code.
If you are writing a large project without any comment you force people to read through quite a bit of it to understand what/where is the part they need to fix and how (assuming you did compartmentalize/modularize the code at all). And this takes some time, especially because even good coders have their own writing styles and you need to familiarize with that too.
If the code you wrote has unclear goal (i.e. workaround for a specific thing, operates on not-that-documented hardware) not writing comments will likely turn it into a trap, where someone tries to optimize it and breaks it and then reverts it (wasting time or worse), or leaves it in there well beyond the time this workaround was necessary and adds a workaround to counter that on top (this last is soo common in java projects I've seen).

The variable names problem seemed the only tractable issue until machine translation becomes good enough to handle niche idioms.

I'd rather prefer the programmer himself being proficient with English. Really, knowing English allows access to vastly better programming resources than in his own local language (maybe except chinese as they have a big enough pool), and keeping most resources in the same language is better for all (so a work published can have the widest possible public).

So it's not like "the programmer needs to know english only to write variable names and comments in english BECAUSE I NEED IT", I think that knowing english (and having internet access) leads to a better programmer overall, and among that there is writing code/comments in english.

Speaking of, that would be an interesting project. A db of good variable names where you are offered a number of multilingual categories (after all, they need someway to actually know what the hell they are looking at BUT I don't think that would actually be completely necessary), with greater specificity within each as needed.
You'd also want to provide some (visual) clues so that they can combine basenames with verbs, but I doubt you'd want to go much further.
It's not perfect, but you'd avoid some of what you experienced, though it wouldn't have helped much in your case.

No offence, but sounds like a central database for init scripts where you can find high-quality init scripts for Sysv so you don't need to write your own every time and add silly bugs.

Good in theory, a pain to actually use in practice, guaranteed to not have anywhere near the penetration it would need to be effective.

[cl333r]

Issue: Some devs won't be able to type specific chars.
Answer: It's their problem.
Just like currently it's the problem of non-English devs to learn English with its ancient/shitty writing rules like "thought", "love", etc.

Issue: Some devs won't be able to read it.
Answer: see answer 1. Writing UTF arabic text doesn't allow native english or russians to read it, but it doesn't mean that Arabs must use English.

Issue: It's the lingua franca.
Answer: it's historic (the US was by far the most important country in this industry and other reasons), not because everybody wanted this. The world is becoming multi-polar. Get used to it. Everything dies over time, including Latin.

Issue: any language after COBOL is madness written by hippie idiots.
This issue was written by a hippie idiot.

Issue: English is used by teams
Answer: And should be used, or Chinese or anything else. You don't tell the whole world what to use. People have to have choice. For every international group of devs there's a myriad of non-international groups of devs and single devs who would much rather not have to learn English which in itself is a multi-year task.

[cl333r]

Issue: Some devs won't be able to type specific chars.
Answer: It's their problem.
Just like currently it's the problem of non-English devs to learn English with its ancient/shitty writing rules like "thought", "love", etc.


Issue: Some devs won't be able to read it.
Answer: see answer 1. Writing UTF arabic text doesn't allow native english or russians to read it, but it doesn't mean that Arabs must use English.

Issue: It's the lingua franca.
Answer: it's historic (the US was by far the most important country in this industry and other reasons), not because everybody wanted this. The world is becoming multi-polar. Get used to it. Everything dies over time, including Latin.

[rosco]

I've seen code made by random guys from Tunisi commented in their local language, and the only way we managed to understand the fuck was doing that code without hiring an interpreter is because they wrote the variable/method names in french.
I mean, I'm not blaming the guys, but whoever thought it was a good idea to not state CLEARLY that codebase comments should be in english for shared stuff should be shouted at, for the least.

If you are talking about Tunisia, their main language is arab, their second language is french. You really want them to comment their code in english while the literacy percentage is 76% ? If you want first world code then purchase it in a first world country.

[starshipeleven]

If you are talking about Tunisia, their main language is arab, their second language is french. You really want them to comment their code in english while the literacy percentage is 76% ? If you want first world code then purchase it in a first world country.

As I said, I'm not blaming them, but the management that thought code from whoever is OK.

[liam]

If you don't know english you don't have access to Stack Overflow, is that a good enough reason to learn it?

Back serious, even broken english is better than $random_local_language because english is very fault-tolerant, you can write sentences with broken syntax and grammar that are still mostly understandable and much better than Google Translating (especially asian->english).

Ok, I admit, i was being a bit hyperbolic with the whole Literate thing (though I was being serious that I tend to develop in a semi-Literate way but not out of any ethical position...it's just that I'm very, very lazy) and yes, english is a (pretty) lightly inflected language so it pidgins quite well despite being pretty order dependent (though less order dependent than I'd expect---I'm not sure why this is, to be honest). So, yeah, broken english comments can be fine as long as they are not misleading.
BTW-> https://research.googleblog.com/2016...r-machine.html

I partly disagree. I mean, ok, writing large comments with the whole pseudocode of the project everywhere is bad (would be great for anyone trying to do maintenance on it, though),

That's, sort of, literate programming (though not precisely what Knuth wrote about, but it certainly gets to the point he was trying to make). Sorry if it wasn't clear what I was referencing b/c, as you say, that's the exact opposite of "letting the code speak for itself" which, I'd imagine, Knuth would say "That's a great idea, if it's only talking to a computer".

but a generic explanation of what each class does at the top (talking of java, C++ has .h files for that), or what each more complex passage is supposed to do is useful for sharing the code (and for you if you forget things).

I'm not arguing. As I said, I don't practice it, but, if I have time, I prefer to read undocumented code as I feel it helps me understand the function/class/lib/whatever better (and a, perhaps, unjustified belief that it helps shape my reasoning so there's less internal translation going on).

Also size matters, and type of code.
If you are writing a large project without any comment you force people to read through quite a bit of it to understand what/where is the part they need to fix and how (assuming you did compartmentalize/modularize the code at all). And this takes some time, especially because even good coders have their own writing styles and you need to familiarize with that too.

OK, now this is something else entirely and I don't know anyone who would create more than a (simple) library without some explanation of what it is and how it works (not paragraphs, mind you, but SOMETHING).
Personally, and I'm sure I'm alone in this, I think the quickest way to grok something is by reading descriptive variable names

If the code you wrote has unclear goal (i.e. workaround for a specific thing, operates on not-that-documented hardware) not writing comments will likely turn it into a trap, where someone tries to optimize it and breaks it and then reverts it (wasting time or worse), or leaves it in there well beyond the time this workaround was necessary and adds a workaround to counter that on top (this last is soo common in java projects I've seen).

This just isn't something I've really come across (web guy, sorry) but if you've got a magic number (I admit, something like this, even if not documented, is something that is likely to stand-out, and thus not be landmine, but it's what occurred to me) somewhere, it better be defined as such otherwise that's being seriously Trump-ish.

I'd rather prefer the programmer himself being proficient with English. Really, knowing English allows access to vastly better programming resources than in his own local language (maybe except chinese as they have a big enough pool), and keeping most resources in the same language is better for all (so a work published can have the widest possible public).

So it's not like "the programmer needs to know english only to write variable names and comments in english BECAUSE I NEED IT", I think that knowing english (and having internet access) leads to a better programmer overall, and among that there is writing code/comments in english.

This is a far subtler point than the one I had thought we were discussing, and I'm not sure I agree with it, but it makes sense. Again, it's just not something I've really had to deal with.

No offence, but sounds like a central database for init scripts where you can find high-quality init scripts for Sysv so you don't need to write your own every time and add silly bugs.

Good in theory, a pain to actually use in practice, guaranteed to not have anywhere near the penetration it would need to be effective.

Considering the direction this discussion went, I can certainly understand why you'd think that, though I am actually thinking about what a minimal implementation might look lik where I wouldn't have to continue treating each language as a snowflake.