I could craft you unreadable code in any language. Someone removing all of the whitespace between their operators is not going to be producing code that I want to be responsible for maintaining... in any language.
Re:Perl 6 Released
by sirclueless on Saturday December 26, 2015 @11:37PM
(#10796427)
Go has an interesting take on whitespace-around-operators -- it starts removing whitespace around binary operators if there are higher precedence operators in the same expression. So, for example, you get:
x = 2 * y
x = 2*y + 5
This is pretty readable. In fact I think it is more readable than the usual convention of "spaces around every binary operator," but it would be untenable without the existence of gofmt. The most common argument against a convention like this is, "subtle bugs will be introduced if the actual precedence is different than the one implied by whitespace," which is why it's great to have a benevolent formatting overlord telling you when or not your formatting is consistent.That's why Perl 5 is still an unbeaten champion in terms of managing the complexity of legacy code. Perl::Tidy (and Perl::Critic) is a super-configurable beast to the extent I've not yet seen in other languages.
You could probably do something similar in Javascript or Python, there are many tools that provide you access to the AST, it's just that no one has written such a tool on top of it (or maybe they have, but they never gained traction).
The funny thing is: most languages have a development philosophy completely opposed to TIMTOWTDI, so they are all trying to write a tool for the one perfect formatting style, not a universal tool with enough flexibility for the different styles. The former usually leads to enough segmentation for every effort to die in its infancy, the latter to Perl::Tidy.
This is especially apparent with Python with its PEP8 standard -- most formatting tools only deal with PEP8 compatibility and only in one direction. Especially with Python, automated code formatting is mistaken for beautification and thus there is a remark in PythonTidy's documentation "Python scripts are usually so good looking that no beautification is required".
I tend to think this is exactly the same thinking that has lead Perl into the mess that's slowly being fixed since about 2005 and I cherish the difference between a language community which has had its painful experience with insufficient tooling and learned from it and the one which hasn't.
Having programmed in Perl for a couple of years and later in Python and JavaScript, I really started to appreciate sigils. There is literally no ambiguity about what's a variable name and what not. Things like reserved words (think JavaScript's commonly used 'klass' monstrosity) are just a non-issue in Perl.
I found dashes are by far easier to type than underscores and I'd certainly have whitespace between operators in my code, so I'd never run into the problem you describe. It is possible to have variables without sigils and in that case, your first example would be a parse error about undeclared users-churn-rate. Also, apostrophes are valid in variable names as well.
your first example would be a parse error about undeclared users-churn-rate
What if users is 10 and churn-rate is 3 and i want to substract the churn-rate from users?You can either use U+2212 MINUS SIGN instead of a hyphen, too. Spaces would probably be preferable from a maintenance point of view, though.
Just use white space! (EDIT: Sorry, I hadn't refreshed for a while, and so didn't see that zoffix (https://news.ycombinator.com/item?id=10795739) beat me to the punch by quite a bit.)
Use the space, Luke ;)
That's been a non-issue for Lisp since 1958...
Lisp is infix though so it's (- some-name other-name), not $some-name-$other-name. I think the former is slightly more readable than (- some_name other_name), while the latter is slightly less readable than $some_name-$other_name.
Something I see no one mentioned, dashes (and apostrophes) aren't the only neat thing you can use in term names. You can use other languages too. $контрольная-работа is a valid variable name.
That's nice. Common Lisp implementations, too, allow any characters in symbol names, even spaces and the empty string. Javascript allows wide character set too. I think it's good that languages break out of [a-zA-Z_-]. That said, I'd use pretty limited charset in internationally developed multi-OS code base. People have different keyboards, input systems, knowledge etc.
That's something I wouldn't like to see in source code, as I wouldn't have a clue how to type it.
How do Russians see that issue? (Is it Russian?)
I think you've missed the point: you can program in your native tongue. I think the expectation is a Russian company would not care whether you can type their variable names :P
Just because you can doesn't mean you should, but Perl isn't a kind of language that's going to stop you.
...or you could just put whitespace around - when you mean subtract.
It's not that common variable names use dash in the wild. Far more common is method names do. In part because of this clash but also to distinguish method names. Also jees use whitespace!! Assuming that was a serious question.
Then how do you know what this means:
oh, i see ... they are prefixed with $. so it's: Hm... still a bit confusing. But ok. It can be avoided by avoiding dashes in variable names.