4 ms·

if you can agree that i got arguments that convince - i do you the favor. :)

by Merkur 11y ago

fixxer 11y ago
I agree that you have raised an argument. I haven't read anything to indicate you understand the issue at a higher level. It would definitely help me respect your argument as sincere if you argued the counter with sophistication.
- Merkur 11y ago
  okay, i'll jump :) 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.
  - 0xdeadbeefbabe 11y ago
    > 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. I put up with whatever semantics are necessary to get the CPU to do the right thing, but I'm more excited about CPUs than semantics.
    - Merkur 11y ago
      well, i see - my statement was flawed. :)
      - 0xdeadbeefbabe 11y ago
        You stand corrected then :) (or not). Does this comment thing make you want to flee to the safety of Java? I would put up with Java semantics if I were fulfilling a community service sentence.
        Merkur 11y ago
        Actually it would remind me on C. It did not even support a redundant comment token, and of course they did not used a comment to mark directives. go troll your self. I am always open to argue, but you have no leverage to be snarky.
        fixxer 11y ago
        Your entire tirade is a troll. You got an answer from Fitz (looked reasonable to me), but you didn't like it. So you decided to take the debate to HN?! Nothing productive ever happens like this. This is some teenage angst diarrhea. Fork the project and write your own solution. Show us all how fucking brilliant you are.
        Merkur 11y ago
        while arguing against your self is nice practice - diarrhea is just... you know... really messy. I hope you get well soon. :)

if you can agree that i got arguments that convince - i do you the favor. :)

by Merkur 11y ago

if you can agree that i got arguments that convince - i do you the favor. :)

I agree that you have raised an argument. I haven't read anything to indicate you understand the issue at a higher level. It would definitely help me respect your argument as sincere if you argued the counter with sophistication.

Merkur 11y ago
okay, i'll jump :) 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.
- 0xdeadbeefbabe 11y ago
  > 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. I put up with whatever semantics are necessary to get the CPU to do the right thing, but I'm more excited about CPUs than semantics.
  - Merkur 11y ago
    well, i see - my statement was flawed. :)
    - 0xdeadbeefbabe 11y ago
      You stand corrected then :) (or not). Does this comment thing make you want to flee to the safety of Java? I would put up with Java semantics if I were fulfilling a community service sentence.
      - Merkur 11y ago
        Actually it would remind me on C. It did not even support a redundant comment token, and of course they did not used a comment to mark directives. go troll your self. I am always open to argue, but you have no leverage to be snarky.
        fixxer 11y ago
        Your entire tirade is a troll. You got an answer from Fitz (looked reasonable to me), but you didn't like it. So you decided to take the debate to HN?! Nothing productive ever happens like this. This is some teenage angst diarrhea. Fork the project and write your own solution. Show us all how fucking brilliant you are.
        Merkur 11y ago
        while arguing against your self is nice practice - diarrhea is just... you know... really messy. I hope you get well soon. :)