thx!
431 karma · joined February 17, 2015
go troll your self. I am always open to argue, but you have no leverage to be snarky.
1) First of all change is not nessesary - because within the current "comment directive convention" the tooling needs can be achived. Even more so - they can be achived without changing the current spec of the language.
2) As I learned during this discussion there are "comment directive convention" that are older as go 1.4. I could imaging they play a role deep inside the go tooling. i.e. I could imaging that the cgo stuff has some deep roots. It would some work to change all occurences - that is glass clear - because even now there are legacy directives // +build //link that are not updated to the "new convention" //go: foo
3) I dont know about the internal mechanism that the go team needs to observce to change the spec of a language, that is perhaps in wide productive use within the google. But i can imagin there is procedure. Changing the spec meight just not be possible before Go 2.0 because of policy.
4) It meight not be desired to introduce something that smells like a macro language into the code. There meight be some animosity againt it - give the clean code philosopy that Go aimes for.
No, i dont realy believe that. I am Sorry to have accused! On contrary: The yacc tool gives great power to expand the language. But yacc is a heavy lifting tool and not something like a macro every one could use. Its also not part of the spec, just given as magic comment - no prommise made.
5) One counter argument that is invalid: I am pretty sure the go team cares about semantic. :-) All programmers do breath semantic. Of course there are different tastes.
6) You basicly cant prevent magic... in comments or otherwise its the reason its called magic.
7) those commented directives can stay in all levels of the build process - without adaptions of the spec. This means tools have the potential to hook on source, on ast, etc.
My argument is semantic? Yes it is! In my optinion thats the reason my argument is so strong.
Please dont tell me you dont see a problem between //go: foor and //todo: bar - the first instructing some tool to change stuff in your build, the later merly mention that there is something left to do here.
A directive like #todo: bar - is a great example for a great tool in the chain. the go tool could look for a "todo" command and this todo command could print out a warning that the code should not be released because XX todos arn't done. If the go tool would'nt find a "todo" command it could warn me that a tool in the chain is missing. I could evaluate in decide to use get this tool, or choose to ignore it.
This would be imposible if comments are missused as directives!
IF has a meaning - and it always have this meaning. FUNC has a meaning - always the same. // are comments. The meaning of comments is to communicate with humans.
We know the principal of "overloading" syntax. Things can have a different meaning in a different context. One could argue using //go: is overloading the comment. BUT: Go is not a language that do's overloading - in fact its philosophy is against overloading, as it is against generics. (and I realy like this philosophy!)
I argue that directives to the tool chain should not apear in a comment - because a directive to the tool chain has a different & incompatible meaning than a comment.
I argue future: There is a need for directives to the tool chain in the Go source code. The go-team has this need, and there can be great things done with such e mechanism. The go community will do great things with directives! I see tons of use cases for godep. I see tons of use cases for debuggers, profilers and all kinds of other tools.
The go-team not only implements go, they also set an example to the usage of the language. If they misuse comments to express directives, other projects will eventualy follow.
But what will happens in the long run if we embrace that example and use //foo: bar as directives for our tool chains?
The go tool chain could not generate meaningfull errors about missing tools, or syntax errors in directives. Also: Comments would not be safe to communicate with fellow programmers - who knows that kind of tools where used in my dependencies? And what kinds of //foo: should be marked pink in my editor? All of em?
All this could be solved by using an other syntax for directives. I do not care if its # or @ or #! or whatever - as long as it is not a comment.
I also have no argument about macros, generics or whatever. I just want go to be unambiguous.
A macro processor could be one of those tools in the chain. There could be other (and Go implements other use cases!)
I would also argue that a macro preprocessor do'snt need to "parse comments", it could parse any syntax the preprocessor wants to (and remove it from source befor the compiler sees it) In fact my point is, that parsing comments at all is a very bad idea.
But my argument is NOT about, if Go needs a macro processor, or not. (i think it dont!) My argument is about the syntax of the directive.
I argue about the syntax of declaring "Here comes something that is not Go Language!" I argue that this syntax should not be a comment - because a comment is part of the Go Language. (...among other reasons i stated in this discussion)
//todo: bar
to do stuff with the code, and makes the program fail because it's not done, because you don't know about it. with a #todo: bar the go tool chain would catch this error
the main problem is not technologie but semantic. If you agree with me that the meaning of a comments is communication between humans, than you must also agree - in my opinion - that comments can not be directives to a tool chain.
It is ambiguous. It is error prone. It is easily solved using an other token.
And in the long run it may lead to madness like Java testing and documenting frameworks.
as for technical problems - I think some really bad ones are mentioned in this very discussion!
http://tutorial.ponylang.org/capabilities/introduction/ is the best concise description why concurrency is hard I read until now.
Got burned twice. Took me 3 years to recover from the Last time. Just finished cleaning my Appartement from 3 years worth of trash. I am so relived!
If You try to work through it you just Drive your self deeper. Scaling back to halve time may work, but its realy the responsibility that kills you.
Sports, Arts, Travel Are helpfull and Friends! Tell Your Friends You Are burned, Tell them You will try to kick em out Your Life, and Tell them they should insist - they should not stop calling you even if you push em back.
Good luck! And next time: Take an early vacation before your Brain is fucked.