I have some negative opinions about syntax.
Hoon Hwangbo
These are most related about favorite, and just nothing if makers and
community ignores this.
But it's hard to believe that nobody cares about these problems.
I wish to hear your opinions if you care.
If I'm thinking wrong, please let me know! And I'll change my mind.
1. BACKWORD DECLARATION
The language document describes backward declaration is more clear and
regular.
But i cannot agree with it. These are document sample.
int* a, b; // Declares a to be a pointer but not b.
var a, b *int; // Declares both to be pointers. This is clearer
and more regular.
What's differ? It's just reversed only. Nothing changed about
punctuations.
Meaningless "var" keyword added. And it's still confused. Because
separator "," is still between variables. And even more confusing
because keywords are surrounding identifiers. I'll feel hard to
recognize "," if syntax highlight applied. "var" and "int" will be
highlighted.
In fact, old style is not confusing. Confusing is old C compiler.
Because it processes as valid even code like this:
int* a, b; // Valid.
int *a, b; // Valid too. I'm not smart enough to figure out
what's this.
I cannot understand why those white-spaces are ignored. Of course
there're so many reasons. Anyway, that's wired in my eyes.
This is not confusing if compiler prohibits later one.
int* a, b; // Both of a, b are pointer to int. Because int*
is pointer type notation.
int *a, b; // Syntax error.
// Because prefixed star(*a) is just value-of a.
Does not mean a pointer type.
And this does not require any additional typing characters like "var".
2. CASE-FOR-VISIBILITY
In my brain:
- lower case = Common, normal things. Normal words.
- Upper Case = Unique, special things. Name of unique thing.
- ALL UPPERCASE = Things need special care, a kind of warning.
I'm not an American but I learned as above when I learning English.
I can't feel any specialty on instance member name.
I believe lowercase means more common, less, invisible, usual, and
uppercase is opposite.
Examples:
- local < Global
- common < Unique
- variable < CONSTANT
- instance member < Class Name
Of course this is possible:
- private member < Public Member.
But in view of code users:
a.Member().Member().Member();
c = a.Method(b.Method());
SO MANY UPPERCASES! What so many special things? This is nonsense.
I'm not a machine, and I feel very uncomfortable with these. Well
classified framework with nice namespaces have less uppercase
characters.
Some languages eliminated all uppercase character on method name. You
may know what it is.
This is worst idea I've ever experienced. This is disaster.
Why? Because it destroys readability without any better reason. This
is your reason.
"The case-for-visibility rule is unlikely to change however; it's
one of our favorite features of Go."
No reason. But if this is really a favorite problem, I have nothing to
say more. That's your free. And I'll be depressed if I have a chance
to using Go.
If makers really hate to marking "public" access so much, it maybe
better eliminating public access feature. No public member. All
private.
Communications only can be done through interfaces. Interface with
field definition.
Or put a special character like "@" before method name for public
members. Any of them will be better to read than uppercase started
member.
COMMENT
I believe code should be read easily from anyone. I felt uncomfortable
when using languages ignoring visual readability. I wish Go to be a
more nice language at readability structurally. Because Go may become
major.
Please think about these again. Of course, English is foreign language
for me, so this maybe just a misunderstanding.
PS: UNICODE IDENTIFIER
First, you have no need to worry about using identifiers with unicode
characters like Japanese. Because nobody will use it. All programmer
uses Roman characters only.
This is not a joke. I'm Korean. And I never seen any people who use
Korean character as identifier even in languages supports unicode
identifier like VB or C#. Some people writes all text in source code
in English even comments. There are many reasons.
- Keywords and other predefined anything must be written in English.
- It's incredibly hard to switching and managing IME (or input context
or etc.) state during typing.
- Source code with mixed language more hard to be read.
- It's not compatible with code using other language.
You cannot even read them if you have no font.
- Many programs doesn't support Unicode properly.
So using unicode in source code promises unhappy future.
- We have to read English documents.
Can you even input those '日本語' text on your keyboard? I can't too.
And sampled characters are a kind of Japanese Kanji, especially harder
to input.
I can't understand why you worry about this. You should know nothing
about this topic.
Programmers use local characters in source code are all fool even
does't know above thing.
It'll be better limiting identifier characters as roman characters to
prevent those foolish.
And this is system-programming language. Not a script language for
newbies.
Rob 'Commander' Pike
Lots has been said about this topic in public and in the FAQ. It's different from C and different for good reasons. After a while it becomes natural, as does any reasonable syntax.
In English, capital words (such as English) are "proper nouns". They're important, public things like names and places. The analogy with public and private names inside a package is a bit of a stretch but does make sense. Public things are more important, and so they're capital. Again, it takes some getting used to but, much more than the declaration order, really starts to feel right. The ability to glance at a name in a package and know, without finding its declaration (or some keyword somewhere near the declaration) that it is a publicly visible name, is a great thing that more than makes up for the inability to use some of the styles you mention.
Some of us feel this is one of Go's best small features.
> COMMENT
>
> I believe code should be read easily from anyone. I felt uncomfortable
> when using languages ignoring visual readability. I wish Go to be a
> more nice language at readability structurally. Because Go may become
> major.
>
> Please think about these again. Of course, English is foreign language
> for me, so this maybe just a misunderstanding.
Thanks for your thoughtful input. However, the design does have a lot of thought behind it and on these issues at least is unlikely to change.
Thanks very much for this input. It means a lot.
-rob
Hoon Hwangbo
great value.
RogerV
programmer, then the variable/type declaration order will seem
completely natural.
It doesn't take that long in coding Go to where it becomes a non-issue
adam_smith
Maybe more importantly it makes it easier to write some things in a
sane way. E.g:
ForEach(func(elem Element) {
processElem(elem):
// do more stuff
// ...
})
Without the func keyword I am not sure how this could have been done
without complicated parsing rules.
In many cases it can be a lot easier to read. E.g.
var size struct { width, height float }
vs
struct { float width, height } size
In the latter case the name of the variable get so far down the line
that when scanning down code lines it is not easy to spot. I'd say
when you a reading a piece of code the first thing you look at is a
variables name and then you want to find the declaration to see what
the type is. So the first question is the name and the second question
is the type.
> - Keywords and other predefined anything must be written in English.
> - It's incredibly hard to switching and managing IME (or input context
> or etc.) state during typing.
> - Source code with mixed language more hard to be read.
> - It's not compatible with code using other language.
> You cannot even read them if you have no font.
> - Many programs doesn't support Unicode properly.
> So using unicode in source code promises unhappy future.
> - We have to read English documents.
I am not a native english speaker either and agree that one should
write code mostly in english. However I disagree strongly that unicode
identifiers are useless. If you implement algorithms for which there
is a good mathematical description it can often be nice to be able to
use greek letter for the variables just as in the math equations.
Often this can be complicated stuff you can't understand by just
reading the code. You need to have the paper with the math equations
in front of you. Then it is helpful if it is easy to recognize
variables and constants in the math equation in the code.
dizm
I'm experimenting with gfmt, a sort of conjugate gofmt.
gfmt takes source in my own personal writing style and produces proper
Go source.
- dave
Ryanne Dolan
I agree that math algos are a common place to use symbols, greek letters, etc. Seeing vars like alphaomega is painful...
But there is a problem with using alpha and omega even in unicode form. Code is usually not meant to be read by mathematicians and should ideally be readable by non-domain experts. Alphaomega might be meaningul to some people, but perhaps velocity, inches, learningRate etc are better names.
In the rare case that alphaomega is more descriptive than learningRate, unicode works but is clumsy to type. I'd more likely write alphaomega than look up the unicode for the respective symbols.
Sun's FORTESS language has it right. You can use a LaTeX-ish language for naming variables, and then render the ascii source code into unicode for publication or easier reading. That way you have the best of both worlds... ascii typing but unicode viewing.
I love that the Go compiler supports unicode cuz it is useful in strings, even if it is bad practice to write unicode variables. For this reason I don't think anything should change, but I won't be writing unicode variables anytime soon.
Ryanne
- from my phone -
On Jan 9, 2010 5:28 AM, "adam_smith" <erik.e...@gmail.com> wrote:
I am fine with type coming last. It is fine when you get used to it.
Maybe more importantly it makes it easier to write some things in a
sane way. E.g:
ForEach(func(elem Element) {
processElem(elem):
// do more stuff
// ...
})
Without the func keyword I am not sure how this could have been done
without complicated parsing rules.
In many cases it can be a lot easier to read. E.g.
var size struct { width, height float }
vs
struct { float width, height } size
In the latter case the name of the variable get so far down the line
that when scanning down code lines it is not easy to spot. I'd say
when you a reading a piece of code the first thing you look at is a
variables name and then you want to find the declaration to see what
the type is. So the first question is the name and the second question
is the type.
> - Keywords and other predefined anything must be written in English. > - It's incredibly hard to ...