FAQ
Resuming from misplaced github.com thread
<https://github.com/golang/go/issues/11586>.

I'm interested in exploring (and maybe coding/contributing) an addition
that would allow individual source files to identify their own chain of
interpreters (somewhat akin to the sha-bang line of shell scripts).

//!FILTER github.com/Osndok/golang-braces/cmd/go-fix-braces
//!FILTER github.com/DAddYE/igo/cmd/indention-instead-of-braces arg1 arg2
//!FILTER /usr/bin/cpp -Dkey=value - -
//!FILTER /usr/bin/sed -E 's/oneThing/another/g'

#define MACROS ARE_NOW_ENABLED

func main()
{
//the rest of the file is normal (with the above filter chain)
}
Which would imply that, rather than go-build acting on: "cat source.go", it
would be acting on "tail +5 source.go | $GOPATH/bin/go-fix-braces |
$GOPATH/bin/indention-instead-of... arg1 arg2 | cpp - - | sed". Does that
make sense?

As seen in the first two lines, I was thinking that it would not be too
hard to recursively call "go build" if needed for the additional ease of
go's fetch/build magic.

The idea being... if anyone:
* is so terribly bothered by any particular/trivial golang design choice
that it might exclude them, and
* is a sufficiently advanced programmer to encode the minor difference in a
filter

...then the community at large is probably better off having them "in" the
golang corner.

What's more... when combined with github, it would provide an easy
mechanism for the owners/moderators of golang to gauge what is important to
the community (that which they invest time in, and are using) by scanning
go repos for an easy-to-match string, and counting/sorting uniques.

There are a few major drawbacks, of course, the biggest of which is
probably obvious:

//!FILTER rm -rf /some/important/file
>

...which could wreck havoc in build servers (don't build as root!). I'm not
sure that it's technically any more dangerous than a classic Makefile, of
course, since a makefile can execute arbitrary code anyway... :-/ ?

Therefore, presuming this is not something immediately desired and
acceptable in the official golang repo, I'd be quite content with an answer
to these questions (to whoever knows):
* at a minimum, what points in the source would need the changes/additional
code (where, exactly, are source files read?), and
* if developed, what conditions (if any) might allow such a feature to be
accepted into the official repo?

-

Since my original posting, I realize that go has already seen cases where
such a thing might be useful (early breakage), and might ease 1.x to 2.0
transitions (or the like).

My current understanding is that it would need several environment
variables:
(1) something to prevent recursion loops (GO_FILTERS_APPLYING?), csv of the
'stack' of filters we are building
(2) something to allow graceful obsolescence of filters on the filter-side
(GOLANG_MAJOR & GOLANG_MINOR versions?) or, perhaps, an understanding that
any well known filter effect that happens to be merged into golang proper
could be detected and simply not applied, and
(3) an environment variable to simply not evaluate filters (causing build
to break) for build server safety

I look forward to reading other's thoughts on this idea. Thanks for your
time and consideration, in advance.

--
Robert Hailey


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Florin Patan at Jul 8, 2015 at 8:39 am
    Hi,


    Here are some problems with this idea (in no particular order, definitely
    missing a few more):
    - it makes the tooling harder to use. What should my IDE do when I get a
    source like this? How do I parse it, validate it, perform static analysis
    on it?
    - how does this integrate with existing standard Go syntax when reusing
    packages? Say I'm having a replacement for func to f. Now what? If I have a
    function that does this:
    f Demo() f(int){
         return f(i int) {
             println(i)
         }
    }
    How do I use it in my code base? If I start using the same filters this
    works until the next package from a different author comes in and it
    decides that function keyword should be called fun. Then what?
    - language syntax based on environment variables is a terrible idea. People
    have sometimes a hard time to understand how to set GOPATH or where to do
    it so controlling how the source is processed via environment variables
    would make a terrible experience for people
    - people will always dislike things to a (any) language. For example I find
    Haskell horrible so I just stay away from it, I'm not trying to change how
    Haskell looks like because it should fit into my view. And if I would need
    to use it then I would use it and that's it. The nice part of Go, which
    people seem to forget, is that it is simple so why change it?

    What do you think? How should these be solved?


    Florin
    On Monday, July 6, 2015 at 9:57:06 AM UTC+2, Robert Hailey wrote:


    Resuming from misplaced github.com thread
    <https://github.com/golang/go/issues/11586>.

    I'm interested in exploring (and maybe coding/contributing) an addition
    that would allow individual source files to identify their own chain of
    interpreters (somewhat akin to the sha-bang line of shell scripts).

    //!FILTER github.com/Osndok/golang-braces/cmd/go-fix-braces
    //!FILTER github.com/DAddYE/igo/cmd/indention-instead-of-braces arg1 arg2
    //!FILTER /usr/bin/cpp -Dkey=value - -
    //!FILTER /usr/bin/sed -E 's/oneThing/another/g'

    #define MACROS ARE_NOW_ENABLED

    func main()
    {
    //the rest of the file is normal (with the above filter chain)
    }
    Which would imply that, rather than go-build acting on: "cat source.go",
    it would be acting on "tail +5 source.go | $GOPATH/bin/go-fix-braces |
    $GOPATH/bin/indention-instead-of... arg1 arg2 | cpp - - | sed". Does that
    make sense?

    As seen in the first two lines, I was thinking that it would not be too
    hard to recursively call "go build" if needed for the additional ease of
    go's fetch/build magic.

    The idea being... if anyone:
    * is so terribly bothered by any particular/trivial golang design choice
    that it might exclude them, and
    * is a sufficiently advanced programmer to encode the minor difference in
    a filter

    ...then the community at large is probably better off having them "in" the
    golang corner.

    What's more... when combined with github, it would provide an easy
    mechanism for the owners/moderators of golang to gauge what is important to
    the community (that which they invest time in, and are using) by scanning
    go repos for an easy-to-match string, and counting/sorting uniques.

    There are a few major drawbacks, of course, the biggest of which is
    probably obvious:

    //!FILTER rm -rf /some/important/file
    ...which could wreck havoc in build servers (don't build as root!). I'm
    not sure that it's technically any more dangerous than a classic Makefile,
    of course, since a makefile can execute arbitrary code anyway... :-/ ?

    Therefore, presuming this is not something immediately desired and
    acceptable in the official golang repo, I'd be quite content with an answer
    to these questions (to whoever knows):
    * at a minimum, what points in the source would need the
    changes/additional code (where, exactly, are source files read?), and
    * if developed, what conditions (if any) might allow such a feature to be
    accepted into the official repo?

    -

    Since my original posting, I realize that go has already seen cases where
    such a thing might be useful (early breakage), and might ease 1.x to 2.0
    transitions (or the like).

    My current understanding is that it would need several environment
    variables:
    (1) something to prevent recursion loops (GO_FILTERS_APPLYING?), csv of
    the 'stack' of filters we are building
    (2) something to allow graceful obsolescence of filters on the filter-side
    (GOLANG_MAJOR & GOLANG_MINOR versions?) or, perhaps, an understanding that
    any well known filter effect that happens to be merged into golang proper
    could be detected and simply not applied, and
    (3) an environment variable to simply not evaluate filters (causing build
    to break) for build server safety

    I look forward to reading other's thoughts on this idea. Thanks for your
    time and consideration, in advance.

    --
    Robert Hailey

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 10, 2015 at 1:42 am

    On Wednesday, July 8, 2015 at 3:39:43 AM UTC-5, Florin Patan wrote:
    Hi,
    Hi Florin! Sorry for the delay, apparently I'm not getting notifications of
    replies!

    Here are some problems with this idea (in no particular order, definitely
    missing a few more):
    If you think of any more, do tell!

    - it makes the tooling harder to use. What should my IDE do when I get a
    source like this? How do I parse it, validate it, perform static analysis
    on it?
    It's interesting that you mention the IDE, because the only IDE/editor I
    have tried with go was actually fine with the alternative brace position
    (only the compiler was not).

    I totally understand how such things like line numbers could be thrown off
    if a filter added/removed lines; and I understand how syntax highlighting
    would become much less useful the further away from the canonical syntax it
    became... but really this is a question for the IDE & filter, not really a
    mark against the utility of the filter idea itself.

    More to the point, present tools might break, but I would expect that
    future tools could simply operate on the filtered output. Surly it would be
    easy enough to provide another go verb that simply applies the filters,
    outputing the canon go code to stdout.

    - how does this integrate with existing standard Go syntax when reusing
    packages? Say I'm having a replacement for func to f. Now what? If I have a
    function that does this:
    f Demo() f(int){
    return f(i int) {
    println(i)
    }
    }
    Ah... this one's easy. My idea is strictly confined to the
    textual/unix-pipe filtering of individual files. No mechanism to apply it
    across an entire project... so if an author wanted to use a particular
    filter set for all his/her work, there would simply be a ritualistic
    header... if an individual file was copied into another project to be
    hacked on, the filters would follow with it (until/unless changed), and in
    your case specifically... the go compiler would see "func Demo()
    func(int)..." and everything would link as expected (a function named Demo,
    usable from unfiltered code).

    How do I use it in my code base? If I start using the same filters this
    works until the next package from a different author comes in and it
    decides that function keyword should be called fun. Then what?
    I don't understand what the issue would be. Some authors might like to
    fully spell out "function".... what difference would that make anywhere?

    - language syntax based on environment variables is a terrible idea. People
    have sometimes a hard time to understand how to set GOPATH or where to do
    it so controlling how the source is processed via environment variables
    would make a terrible experience for people
    The environment variables are only to aid in the more intelligent filters
    knowing when they are obsolete (communicating the go language version).
    IMO, even though it is more implicit, this is more straight-forward than,
    say, including a version condition in the call for a filter, which must
    then be updated en-mass.

    - people will always dislike things to a (any) language. For example I find
    Haskell horrible so I just stay away from it, I'm not trying to change how
    Haskell looks like because it should fit into my view. And if I would need
    to use it then I would use it and that's it. The nice part of Go, which
    people seem to forget, is that it is simple so why change it?
    Easy... WORLD DOMINATION. Ha ha...

    What I mean is... suppose all the Python programmers found out... if I use
    filter X, and can ignore/not-do Y, then my Python code can be compiled by
    go! and use the whole goland world of goodness. Then further suppose all
    the Java programmers found out a condition similar... that they could be
    freed from the confines of the VM! And the C programmers, etc, etc.

    The present fact that I see is this... developers are simultaneously
    attracted TO golang for some causes, and REPELLED for causes so simple that
    many are motivated to write their own translators. Rather than having a
    bunch of golang forks (like igo), complicating the go compiler, or have
    developers needlessly shooed away or working in misery... why not take an
    easy and straight-forward approach that makes everyone happy?

    What do you think? How should these be solved?
    >

    I think the IDE is the only major hurdle I've considered ATM... and it's
    not really golang's problem. One might say to fix the foundation (compiler)
    and the super structure will follow (doesn't everyone love IDE
    complexity?)... but I'm not sure that's even necessary.

    As I see it, those willing to live with filters will also likely not mind a
    few missing features or IDE breakage, and what's more... if the go
    community decides that any particular filter is actually worth having in
    the language (some time down the road), then the IDE will follow... but the
    crucial point is that we would have had the SIGNAL (information and
    initiative is key!).

    --
    Robert Hailey

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Florin Patan at Jul 11, 2015 at 12:48 pm
    It's not only IDEs, people use other tools as well to leverage static
    analysis and so on. But the point is, the proposal needlessly complicates
    the whole ecosystem just because some people don't agree with the syntax of
    the language.

    What does Java to to ease out the adoption over C? C++ over C, any other
    language over other languages?

    If syntax is something that one doesn't like, then one shouldn't use the
    language.

    Here's my programming experience as a PHP programmer:
    - there are 4 major different style guides: Zend, Symfony2 (which is subset
    of PSR1/2 iirc), PSR1/PSR2, PEAR
    - there's a bunch more others as many projects don't adhere to these
    - of course each company has it's own style guide which (usually takes days
    or even weeks to adopt, and time to configure your tools to work with,
    'cause no one has has time to write a tool to format the code as it's in
    their code style document, which document is always outdated or doesn't fit
    in with some of the older code, or newer code or code in general)

    Here's what I've found on a quick search on Google for:

    - Ruby, taken from http://stackoverflow.com/a/4187763/951414 (but there's a
    bunch more on a search for "ruby style guide"):
      - The Unofficial Ruby Usage Guide
      - Ruby and Rails Style Guide
      - Elements of Ruby Style
      - Christian Neukirchen's Ruby Style Guide

    - Python:
      - PEP 8 (I hope it's the right one)
      - wxPython (for wxPython, whatever that means)

    - Java:
      - too many to count (seems every shop has it's owns stuff / I'm too lazy
    to find common ones)

    - C
      - this one returns 426 million results (as opposed to Java which had a
    small 12 million results)

    - C++
      - there's only 1.2 million results for this one

    And that's the styles only. I'm not counting on how many people in language
    XYZ would like func to be function or f or fun or whatever.

    Now, looking at the above things, consider that one moves between projects
    (in the same language) and has some contributions to other projects as
    well. If you've ever done this, for real, you've surely had at least one PR
    rejected because you mixed up the code style. Or, if you didn't, you had
    for sure spent some time changing the code to match the style of the
    project you were contributing / working on. And seriously, I've had to
    review so much code in my life where I was doing comments like: this curly
    braces is on the wrong line, please use 4 spaces instead of a tab, please
    use 1 tab instead of 4 spaces and so on...

    Here's the fun part: Go compiler doesn't force the source code to have a
    style guide, the go toolchain happens to provide gofmt which settles a
    default style guide.

    The ones who (en)"force" the use of this style are the people in the
    community, which like me, find it good to have a single style and a single
    way to write and read the function keyword. I can only imagine when the fun
    one would have when struct will be replaced by class. Speaking of, please
    come up with an example where package A changes the struct to class,
    package B changes struct to structure and package C, which uses plain old
    boring Go struct keyword, uses both package A and B. You'll notice how it's
    not an IDE problem, it's a problem that you, the developer, will have to
    face it (see below).


    Look at the following example and tell me it you would want to work within
    such an environment:

    // package: github.com/dlsniper/packageA/packageA.go
    package packageA

    //!FILTER github.com/dlsniper/golang-braces/cmd/go-fix-braces
    //!FILTER
    github.com/dlsniper/golang-class-instead-of-struct/cmd/go-fix-class-struct

    type Exported class
    {
         Demo int
         DemoStruct class
         {
             Demo int
         }
    }


    // package: github.com/dlsniper1/packageB/packageB.go
    package packageB

    //!FILTER github.com/dlsniper1/golang-spaces/cmd/go-fix-spaces
    //!FILTER
    github.com/dlsniper1/golang-structure-instead-of-struct/cmd/go-fix-structure-struct

    type Exported1 structure {
         Demo int
         DemoStruct structure {
             Demo int
         }
    }


    // package: github.com/dlsniper2/packageC/packageC.go
    package packageC

    //!FILTER github.com/dlsniper2/golang-dots-to-php/cmd/go-fix-dots-to-php

    import "github.com/dlsniper/packageA"
    import "github.com/dlsniper1/packageB"

    type Exported2 struct {
         Demo int
         Demo2 packageA->Exported
         Demo3 packageB->Exported1
    }

    Observe how suddenly I need four external tools to build the same source
    code that I could build easily without any of them in normal conditions.
    And for what? So that the two other package authors can feel good about how
    a the standard language syntax is written (which isn't standard anymore
    because of them?) And I don't even talk about the potential issues with
    things like: what about CI pipelines? How should this be handled? What if
    the author of the said tool decides suddently that instead of structure he
    wants now to call them unicorn? Do you suggest to "version" the filter?

    So yes, I'm saying if someone doesn't like that Go community chooses to use
    the style suggested by the go authors then maybe that person should either
    learn how to accept things as they are or embrace other communities /
    programming languages. There are more important things to solve rather than
    how people prefer to write the function keyword or where's the brace
    position.


    Cheers
    On Friday, July 10, 2015 at 3:42:34 AM UTC+2, Robert Hailey wrote:


    On Wednesday, July 8, 2015 at 3:39:43 AM UTC-5, Florin Patan wrote:

    Hi,
    Hi Florin! Sorry for the delay, apparently I'm not getting notifications
    of replies!

    Here are some problems with this idea (in no particular order, definitely
    missing a few more):
    If you think of any more, do tell!

    - it makes the tooling harder to use. What should my IDE do when I get a
    source like this? How do I parse it, validate it, perform static analysis
    on it?
    It's interesting that you mention the IDE, because the only IDE/editor I
    have tried with go was actually fine with the alternative brace position
    (only the compiler was not).

    I totally understand how such things like line numbers could be thrown off
    if a filter added/removed lines; and I understand how syntax highlighting
    would become much less useful the further away from the canonical syntax it
    became... but really this is a question for the IDE & filter, not really a
    mark against the utility of the filter idea itself.

    More to the point, present tools might break, but I would expect that
    future tools could simply operate on the filtered output. Surly it would be
    easy enough to provide another go verb that simply applies the filters,
    outputing the canon go code to stdout.

    - how does this integrate with existing standard Go syntax when reusing
    packages? Say I'm having a replacement for func to f. Now what? If I have a
    function that does this:
    f Demo() f(int){
    return f(i int) {
    println(i)
    }
    }
    Ah... this one's easy. My idea is strictly confined to the
    textual/unix-pipe filtering of individual files. No mechanism to apply it
    across an entire project... so if an author wanted to use a particular
    filter set for all his/her work, there would simply be a ritualistic
    header... if an individual file was copied into another project to be
    hacked on, the filters would follow with it (until/unless changed), and in
    your case specifically... the go compiler would see "func Demo()
    func(int)..." and everything would link as expected (a function named Demo,
    usable from unfiltered code).

    How do I use it in my code base? If I start using the same filters this
    works until the next package from a different author comes in and it
    decides that function keyword should be called fun. Then what?
    I don't understand what the issue would be. Some authors might like to
    fully spell out "function".... what difference would that make anywhere?

    - language syntax based on environment variables is a terrible idea.
    People have sometimes a hard time to understand how to set GOPATH or where
    to do it so controlling how the source is processed via environment
    variables would make a terrible experience for people
    The environment variables are only to aid in the more intelligent filters
    knowing when they are obsolete (communicating the go language version).
    IMO, even though it is more implicit, this is more straight-forward than,
    say, including a version condition in the call for a filter, which must
    then be updated en-mass.

    - people will always dislike things to a (any) language. For example I
    find Haskell horrible so I just stay away from it, I'm not trying to change
    how Haskell looks like because it should fit into my view. And if I would
    need to use it then I would use it and that's it. The nice part of Go,
    which people seem to forget, is that it is simple so why change it?
    Easy... WORLD DOMINATION. Ha ha...

    What I mean is... suppose all the Python programmers found out... if I use
    filter X, and can ignore/not-do Y, then my Python code can be compiled by
    go! and use the whole goland world of goodness. Then further suppose all
    the Java programmers found out a condition similar... that they could be
    freed from the confines of the VM! And the C programmers, etc, etc.

    The present fact that I see is this... developers are simultaneously
    attracted TO golang for some causes, and REPELLED for causes so simple that
    many are motivated to write their own translators. Rather than having a
    bunch of golang forks (like igo), complicating the go compiler, or have
    developers needlessly shooed away or working in misery... why not take an
    easy and straight-forward approach that makes everyone happy?

    What do you think? How should these be solved?
    I think the IDE is the only major hurdle I've considered ATM... and it's
    not really golang's problem. One might say to fix the foundation (compiler)
    and the super structure will follow (doesn't everyone love IDE
    complexity?)... but I'm not sure that's even necessary.

    As I see it, those willing to live with filters will also likely not mind
    a few missing features or IDE breakage, and what's more... if the go
    community decides that any particular filter is actually worth having in
    the language (some time down the road), then the IDE will follow... but the
    crucial point is that we would have had the SIGNAL (information and
    initiative is key!).

    --
    Robert Hailey
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Jul 8, 2015 at 9:06 am

    On Monday, 6 July 2015 10:57:06 UTC+3, Robert Hailey wrote:

    Resuming from misplaced github.com thread
    <https://github.com/golang/go/issues/11586>.

    I'm interested in exploring (and maybe coding/contributing) an addition
    that would allow individual source files to identify their own chain of
    interpreters (somewhat akin to the sha-bang line of shell scripts).

    //!FILTER github.com/Osndok/golang-braces/cmd/go-fix-braces
    //!FILTER github.com/DAddYE/igo/cmd/indention-instead-of-braces arg1 arg2
    //!FILTER /usr/bin/cpp -Dkey=value - -
    //!FILTER /usr/bin/sed -E 's/oneThing/another/g'

    #define MACROS ARE_NOW_ENABLED

    func main()
    {
    //the rest of the file is normal (with the above filter chain)
    }
    Which would imply that, rather than go-build acting on: "cat source.go",
    it would be acting on "tail +5 source.go | $GOPATH/bin/go-fix-braces |
    $GOPATH/bin/indention-instead-of... arg1 arg2 | cpp - - | sed". Does that
    make sense?

    As seen in the first two lines, I was thinking that it would not be too
    hard to recursively call "go build" if needed for the additional ease of
    go's fetch/build magic.

    The idea being... if anyone:
    * is so terribly bothered by any particular/trivial golang design choice
    that it might exclude them, and
    * is a sufficiently advanced programmer to encode the minor difference in
    a filter

    ...then the community at large is probably better off having them "in" the
    golang corner.
    Generally, I think it's a bad idea... it's making minor improvements to the
    language that break compatibility with tooling and IDEs. It makes build
    times less predictable (longer). Most important of all, it makes harder to
    read arbitrary Go code. By making such changes trivial, people are going to
    make such changes lightly - which will make the ecosystem worse.

    It's a simple way to shoot yourself in the foot... And currently you can
    use "go generate", which requires more effort. I.e. don't make minor
    language changes, make a proper DSL that solves the problem much better...
    e.g. yacc

    + Egon

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Jul 9, 2015 at 4:26 am

    On Wed, Jul 8, 2015 at 7:06 PM, Egon wrote:
    And currently you can use "go generate",
    Yes, if you want m4-style macros, the best approach is probably "go
    generate". For example, the "/usr/bin/cpp" path you give in your
    example won't fly for Windows users.

    See http://blog.golang.org/generate

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 10, 2015 at 2:02 am

    On Wednesday, July 8, 2015 at 11:27:05 PM UTC-5, Nigel Tao wrote:
    On Wed, Jul 8, 2015 at 7:06 PM, Egon <egon...@gmail.com <javascript:>>
    wrote:
    And currently you can use "go generate",
    Yes, if you want m4-style macros, the best approach is probably "go
    generate". For example, the "/usr/bin/cpp" path you give in your
    example won't fly for Windows users.
    A great point!

    I'm not concerned with non-posix operating systems, but it would easy
    enough to have a convention (i.e. "tool <input.tmp> <output.tmp>") to work
    around this issue.... I kinda prefer pipes, myself.

    Yes. I saw that long before I considered any of this. :-)

    --
    Robert Hailey


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 10, 2015 at 1:59 am

    On Wednesday, July 8, 2015 at 4:06:49 AM UTC-5, Egon wrote:

    Generally, I think it's a bad idea...
    I'm sorry you feel that way. If you are primarily troubled by the fact of
    re-introducing the "execute arbitrary code" part of the build process, then
    I can certainly understand! I'm not too fond of that either, but I think
    the benefit outweighs the cost. I you can provide more specifics, I would
    appreciate it.

    it's making minor improvements to the language that break compatibility
    with tooling and IDEs.
    I just addressed this in an earlier post.

    It makes build times less predictable (longer).
    What's the worst case? If (as an author) I could wholesale-copy golangs
    AST, tweak it, and dump valid GO AST... let's say that might DOUBLE the
    compilation time (for a particular file)... so? Is that a problem? If that
    is the cost against me actually being able to do something useful with
    golang, isn't that a "good thing"?

    Most important of all, it makes harder to read arbitrary Go code.
    >

    Not really. I imagine the most common changes you would run into are small
    (braces, spacing)... some (like me) would claim that it actually makes the
    code *easier* to read :)

    The larger & more complex filters would probably end up being prototypical
    features (like generics), and eventually be discarded or merged.

    In either case, I'm sure there would be a verb to produce pure go syntax
    ("go filter"?).

    By making such changes trivial, people are going to make such changes
    lightly - which will make the ecosystem worse.
    Worse? how?

    It's a simple way to shoot yourself in the foot...
    How is this injurious?

    In the expected case, you would get authors that are "bootstrapped" into
    go... they start with hand-holding filters from their previous language,
    and eventually "graduate" to pure go (or go evolves to meet them). Old code
    is either ported, or not, but still would work. What's the problem, exactly?

    And currently you can use "go generate", which requires more effort.
    Yes... "more effort" being key. Surly one of golang's principals is
    avoiding unneccesary complexity (like makefiles and copy/paste generation
    scripts).

    I.e. don't make minor language changes, make a proper DSL that solves the
    problem much better... e.g. yacc
    I'm slightly confused, I thought this is what you were arguing *against*
    when you said it would make go code harder to read. Are you now claiming
    that a 99.9% compliant go file (say... with lonely braces), with a
    different extension (to avoid the go compiler) and require you to install a
    separate tool, would be a "good thing"? or "less effort"?

    --
    Robert Hailey

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Jul 10, 2015 at 8:29 am

    On Friday, 10 July 2015 04:59:53 UTC+3, Robert Hailey wrote:

    On Wednesday, July 8, 2015 at 4:06:49 AM UTC-5, Egon wrote:


    Generally, I think it's a bad idea...
    I'm sorry you feel that way. If you are primarily troubled by the fact of
    re-introducing the "execute arbitrary code" part of the build process, then
    I can certainly understand! I'm not too fond of that either, but I think
    the benefit outweighs the cost. I you can provide more specifics, I would
    appreciate it.

    it's making minor improvements to the language that break compatibility
    with tooling and IDEs.
    I just addressed this in an earlier post.
    It makes build times less predictable (longer).
    What's the worst case? If (as an author) I could wholesale-copy golangs
    AST, tweak it, and dump valid GO AST... let's say that might DOUBLE the
    compilation time (for a particular file)... so? Is that a problem? If that
    is the cost against me actually being able to do something useful with
    golang, isn't that a "good thing"?
    You are thinking only of your particular use-cases not the whole system or
    possible filters. Not how people are going to abuse it... that's what
    programmers do - they try to push the boundaries; which can bite-back very
    easily.

    I can imagine filters that could take hours to compile for 10 lines of
    code. E.g. superoptimizer (http://www.hackersdelight.org/aha/aha.pdf).

    Most important of all, it makes harder to read arbitrary Go code.
    Not really. I imagine the most common changes you would run into are small
    (braces, spacing)... some (like me) would claim that it actually makes the
    code *easier* to read :)
    That's the problem it's only a claim... not a scientific research into
    psychology of coding. I suspect that the consistency across coding-styles
    is better than any coding-style on their own - but I don't have proof
    either. Everywhere when it's discussed whether you should use X or Y in
    coding style -- people say, I prefer Y but nothing bad with X either...
    just be consistent. You lose more with inconsistent projects.

    The larger & more complex filters would probably end up being prototypical
    features (like generics), and eventually be discarded or merged.

    In either case, I'm sure there would be a verb to produce pure go syntax
    ("go filter"?).
    By making such changes trivial, people are going to make such changes
    lightly - which will make the ecosystem worse.
    Worse? how?
    Let's say I wrote my tutorial using filter X, now some-body else comes and
    wants to use some part of my code in their own project. They copy-paste the
    part that they need and it doesn't compile. This in turn either means that
    he'll either add the same filter X... or manually convert the code to their
    own piece.

    It's a simple way to shoot yourself in the foot...
    How is this injurious?

    In the expected case, you would get authors that are "bootstrapped" into
    go... they start with hand-holding filters from their previous language,
    and eventually "graduate" to pure go (or go evolves to meet them). Old code
    is either ported, or not, but still would work. What's the problem, exactly?
    The problem is that such graduation *usually* doesn't happen; they will
    just keep using the training wheels because that's what they are
    comfortable with. Think of JavaScript - how many years it took before
    people started writing JavaScript and not a Java/C dialect of JavaScript?

    For old code, just write a code-converter that converts it into Go... and
    then start cleaning-up the Go code.

    And currently you can use "go generate", which requires more effort.
    Yes... "more effort" being key. Surly one of golang's principals is
    avoiding unneccesary complexity (like makefiles and copy/paste generation
    scripts).
    Code-generation is a very useful tool. e.g. would you want to write 100
    types based on xsd schemas by hand?

    I.e. don't make minor language changes, make a proper DSL that solves the
    problem much better... e.g. yacc
    I'm slightly confused, I thought this is what you were arguing *against*
    when you said it would make go code harder to read. Are you now claiming
    that a 99.9% compliant go file (say... with lonely braces), with a
    different extension (to avoid the go compiler) and require you to install a
    separate tool, would be a "good thing"? or "less effort"?
    What I'm saying that there shouldn't even be a 95% compliant go file. It
    just introduces no benefit, other than satisfying the person who is writing
    it. Basically, I want people to stop bike-shedding. When people want to
    contribute to project X and they need to go over the style guide, fix any
    mistakes, try submit, the maintainers says, fix those places as well...
    instead of just contributing. It's time-wasted. Such minor differences also
    detract from the real bug/problem at hand.

    Minor differences are a time-sink without any measured benefit. (At least I
    have not seen any proper evidence that suggests otherwise.)... sure if you
    want to experiment with other styles - I'm not against it... but...

    Go is not a research nor experimentation language, it's
    a production language that tries to endorse/enforce strict code-conventions
    across the whole ecosystem - to avoid such time-sinks in big projects.

    The benefits of a DSL should outweigh the cost of having a separate tool...
    that way people will use it only when they need to - not when they want to.
    DSLs solve problems that Go can't express easily. Let's say you are
    implementing a constraint resolver. Trying to make it happen with Go syntax
    is very annoying and verbose... trying to mix DSL with Go is a terrible
    abomitaion, but when it's a separate language specifically for that
    problem, you are getting a much bigger benefit with a cleaner result.

    + Egon

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 10, 2015 at 10:32 pm

    On Friday, July 10, 2015 at 3:29:40 AM UTC-5, Egon wrote:
    I can imagine filters that could take hours to compile for 10 lines of
    code. E.g. superoptimizer (http://www.hackersdelight.org/aha/aha.pdf).

    Okay... then, in theory, there may be a way to further optimize builds by
    caching filtered results, or statically applying filters? Sounds good.

    That's the problem it's only a claim... not a scientific research into
    psychology of coding. I suspect that the consistency across coding-styles
    is better than any coding-style on their own - but I don't have proof
    either. Everywhere when it's discussed whether you should use X or Y in
    coding style -- people say, I prefer Y but nothing bad with X either...
    just be consistent. You lose more with inconsistent projects.
    At this point, I'm really doubting the golang utopia of global read/write
    bliss. In particular, I really doubt that go can prevent people from
    writing bad code. Furthermore, if you consider one's natural language, this
    argument falls apart (would we enforce english comments?).

    I'm much more willing to accept that the utopia arguments are an excuse to
    continue to use a simpler (and faster) AST/parser.

    More tersely...
    ( SPEED --> STRICT ) = true
    ( UTOPIA --> STRICT ) = false
    ( STRICT --> UTOPIA) = unconvinced


    Let's say I wrote my tutorial using filter X, now some-body else comes and
    wants to use some part of my code in their own project. They copy-paste the
    part that they need and it doesn't compile.

    +1 for Egon... another good point. This might be what was illuded to
    earlier (without the intemediate explanation)... that people might start
    posting not-quite-golang code snippets on stackoverflow (for example).

    I concede that this has the potential to increase confusion, but expect it
    to be marginal.

    This in turn either means that he'll either add the same filter X... or
    manually convert the code to their own piece.

    If you have the whole file, then you can easily flatten it without any
    manual editing.

    Otherwise, if we find that any particular set of filters are becoming so
    common asto generate this sort of confusion, then I argue that it is a
    "good thing" to get this natural signal/feedback, and would have been a
    "bad thing" to suppress it.

    IMO, the correct course of action (to deal with the growing confusion)
    would be to allocate a separate identifier for this splinter-language...
    say... "golang-bobx", as a separate stackoverflow tag or "community name"
    (if it came to that).

    The problem is that such graduation *usually* doesn't happen; they will
    just keep using the training wheels because that's what they are
    comfortable with. Think of JavaScript - how many years it took before
    people started writing JavaScript and not a Java/C dialect of JavaScript?

    I find it a bit odd that you use an *example* of graduation to disprove
    that graduation happens... but I don't think this is a major contention
    point. Like what I said to Nigel... it's mechanically translatable, so if
    you don't like it, and would prefer to use pure golang, just flatten it. In
    the extreme case, you might even see project forks along these lines
    (killerapp vs killerapp-purego?).

    For old code, just write a code-converter that converts it into Go... and
    then start cleaning-up the Go code.

    As I already spoke towards this, did you have any comments on my
    points/ideas against

    And currently you can use "go generate", which requires more effort.
    Yes... "more effort" being key. Surly one of golang's principals is
    avoiding unneccesary complexity (like makefiles and copy/paste generation
    scripts).
    Code-generation is a very useful tool. e.g. would you want to write 100
    types based on xsd schemas by hand?
    Oh no, I agree! Code generation can be good.

    I think the real question is to this effect. Would it be better to:
    (1) possibly forget to run "go generate", and thus build an
    invalid/inconsistent output, or
    (2) have the timestamp or hash wizardry automatically notice if it needs to
    "regenerate" the code, where the generator is expressed as a 'filter'.

    ?

    What I'm saying that there shouldn't even be a 95% compliant go file. It
    just introduces no benefit, other than satisfying the person who is writing
    it.
    That's quite a strong statement, and I'm sure it is not generally true.

    Basically, I want people to stop bike-shedding. When people want to
    contribute to project X and they need to go over the style guide, fix any
    mistakes, try submit, the maintainers says, fix those places as well...
    instead of just contributing. It's time-wasted. Such minor differences also
    detract from the real bug/problem at hand.
    Yes, that sounds like quite a problem... but it would also seem to be a
    social one (bad maintainers?)... and not one that applying
    mechanical-formatting-force would actually solve (identifier and variable
    names, for example).

    Wouldn't it be better if someone submitted a functionally-useful patch, and
    they said "yea!". Then another (or a "go fmt" machine) submits a
    style-guide-useful patch... "yea!".

    In short, I agree. We need more "yea" and less "nay". In particular, anyone
    else expressing a "yea" to this idea would be nice. :-)

    Minor differences are a time-sink without any measured benefit. (At least I
    have not seen any proper evidence that suggests otherwise.)... sure if you
    want to experiment with other styles - I'm not against it... but...
    ...except, you are against me using other styles... aren't you. As I
    understand your arguments, it would either be wrong for me to publish
    golang-like code or right for the go compiler to exert as much force so as
    to inconvenience that... no?

    Go is ... a production language that tries to endorse/enforce strict
    code-conventions across the whole ecosystem
    I kinda wish you would use stronger terms, but I understand you might not
    speak for "the go community" or... whoever the arbiters of golang features
    may be.

    In particular, when libre software "tries" to "force" humans to do (or not
    do) something, it's usually wrong, philosophically.

    Please don't miss power and subtlety of my suggestion...
    (1) I am *NOT* recommending *any* changes to the golang syntax.... only the
    build process,
    (2) that must be clearly presented at the top of an effected file (forked
    go's... not so much),
    (3) that hopes to avoid and unify reduplicated effort (that *already*
    exists in spades),
    (4) that has the capacity to ameliorate any number of golang's
    barriers-to-entry (google: "50 shades of go"),
    (5) thus letting more people do useful things with go,
    (6) while avoiding pitfalls inherent with an extra 'go generate' step,
    (7) totally answers common objections to golang, and
    (8) forever frees the golang compiler from nuisance-avoiding "tweaks" and
    bike shedding, and
    (9) no longer suppresses developer's creative effort you might not agree
    with (e.g. igo)

    At a cost of...
    (1) a valid build process/machine concern of executing arbitrary code (!),
    (2) that the community might adopt some language constructs you don't like
    (e.g. in stackoverflow), and
    (3) it might get a bit confusing before a true language fork is needed
    ("golang-bobx")

    Have I missed anything?

    --
    Robert Hailey


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon Elbre at Jul 10, 2015 at 11:35 pm

    On Saturday, July 11, 2015, Robert Hailey wrote:
    At this point, I'm really doubting the golang utopia of global read/write
    bliss. In particular, I really doubt that go can prevent people from
    writing bad code. Furthermore, if you consider one's natural language, this
    argument falls apart (would we enforce english comments?).
    I'm much more willing to accept that the utopia arguments are an excuse to
    continue to use a simpler (and faster) AST/parser.

    More tersely...
    ( SPEED --> STRICT ) = true
    ( UTOPIA --> STRICT ) = false
    ( STRICT --> UTOPIA) = unconvinced


    Let's say I wrote my tutorial using filter X, now some-body else comes and
    wants to use some part of my code in their own project. They copy-paste the
    part that they need and it doesn't compile.

    +1 for Egon... another good point. This might be what was illuded to
    earlier (without the intemediate explanation)... that people might start
    posting not-quite-golang code snippets on stackoverflow (for example).

    I concede that this has the potential to increase confusion, but expect it
    to be marginal.

    This in turn either means that he'll either add the same filter X... or
    manually convert the code to their own piece.

    If you have the whole file, then you can easily flatten it without any
    manual editing.

    Otherwise, if we find that any particular set of filters are becoming so
    common asto generate this sort of confusion, then I argue that it is a
    "good thing" to get this natural signal/feedback, and would have been a
    "bad thing" to suppress it.

    IMO, the correct course of action (to deal with the growing confusion)
    would be to allocate a separate identifier for this splinter-language...
    say... "golang-bobx", as a separate stackoverflow tag or "community name"
    (if it came to that).
    And the hole becomes deeper.

    The problem is that such graduation *usually* doesn't happen; they will
    just keep using the training wheels because that's what they are
    comfortable with. Think of JavaScript - how many years it took before
    people started writing JavaScript and not a Java/C dialect of JavaScript?

    I find it a bit odd that you use an *example* of graduation to disprove
    that graduation happens... but I don't think this is a major contention
    point. Like what I said to Nigel... it's mechanically translatable, so if
    you don't like it, and would prefer to use pure golang, just flatten it. In
    the extreme case, you might even see project forks along these lines
    (killerapp vs killerapp-purego?).

    For old code, just write a code-converter that converts it into Go... and
    then start cleaning-up the Go code.

    As I already spoke towards this, did you have any comments on my
    points/ideas against
    Forgot one step, throw away the old code, after validating the new code.

    And currently you can use "go generate", which requires more effort.
    Yes... "more effort" being key. Surly one of golang's principals is
    avoiding unneccesary complexity (like makefiles and copy/paste generation
    scripts).
    Code-generation is a very useful tool. e.g. would you want to write 100
    types based on xsd schemas by hand?
    Oh no, I agree! Code generation can be good.

    I think the real question is to this effect. Would it be better to:
    (1) possibly forget to run "go generate", and thus build an
    invalid/inconsistent output, or
    (2) have the timestamp or hash wizardry automatically notice if it needs
    to "regenerate" the code, where the generator is expressed as a 'filter'.

    ?
    There's no easy way to see that because some generators depend on the
    Internet. eg downloading the latest version of some data and then
    generating based on that.

    What I'm saying that there shouldn't even be a 95% compliant go file. It
    just introduces no benefit, other than satisfying the person who is writing
    it.
    That's quite a strong statement, and I'm sure it is not generally true.
    I would be very surprised to find an example that would provide a
    significant benefit with less than 5% change to Go, that can't be done with
    Go. The closest would probably be generics, but it probably would require
    more syntax changing than 5%.

    Basically, I want people to stop bike-shedding. When people want to
    contribute to project X and they need to go over the style guide, fix any
    mistakes, try submit, the maintainers says, fix those places as well...
    instead of just contributing. It's time-wasted. Such minor differences also
    detract from the real bug/problem at hand.
    Yes, that sounds like quite a problem... but it would also seem to be a
    social one (bad maintainers?)... and not one that applying
    mechanical-formatting-force would actually solve (identifier and variable
    names, for example).

    Wouldn't it be better if someone submitted a functionally-useful patch,
    and they said "yea!". Then another (or a "go fmt" machine) submits a
    style-guide-useful patch... "yea!".
    Instead of getting the correctly formatted patch in the first place?

    And I don't believe people are not going to write formatters for their own
    small syntax differences.

    I agree it's social, but we need to take into account that person after
    programming 2yr probably doesn't know the trade-offs well, 4yr is spent in
    the Danning Kruger effect and at 8yr might have sufficient experience to
    understand the trade-offs. Some people transition through those faster,
    some slower. I.e. We need to make sure that the 6yrs person is creating
    value without unintentionally causing harm. That's the reality... Not
    everyone is an excellent developer, but I do believe people can learn
    faster when surrounded by great code.

    And yes, you will still make mistakes, it's fine and unavoidable...

    In short, I agree. We need more "yea" and less "nay". In particular, anyone
    else expressing a "yea" to this idea would be nice. :-)
    >
    Minor differences are a time-sink without any measured benefit. (At least I
    have not seen any proper evidence that suggests otherwise.)... sure if you
    want to experiment with other styles - I'm not against it... but...
    ...except, you are against me using other styles... aren't you. As I
    understand your arguments, it would either be wrong for me to publish
    golang-like code or right for the go compiler to exert as much force so as
    to inconvenience that... no?
    Yes to the amount that it doesn't hinder other things. I.e. formatting
    cannot be a compiler error because the formatting changes are improved
    independently.

    Go is ... a production language that tries to endorse/enforce strict
    code-conventions across the whole ecosystem
    I kinda wish you would use stronger terms, but I understand you might not
    speak for "the go community" or... whoever the arbiters of golang features
    may be.
    The problem is that the language can only try... people themselves have to
    do the final steps.

    In particular, when libre software "tries" to "force" humans to do (or not
    do) something, it's usually wrong, philosophically.
    So you think it's bad to enforce a safety in case human accidentally raises
    radiation levels over human tolerance threshold?

    The goal of software is to provide value.
    The goal of tools is to make providing value better.
    Tools and software can also produce/reduce waste in their processes.

    You can produce more value by either reducing waste or scaling up...
    Usually the limit is in human hours... The less you produce waste, the more
    you can produce value.

    Please don't miss power and subtlety of my suggestion...
    >

    I understand the power and benefits it may bring. But looking at JavaScript
    and C macro abuses I predict the same thing happening.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 11, 2015 at 6:03 am

    On Friday, July 10, 2015 at 6:36:10 PM UTC-5, Egon wrote:

    I think the real question is to this effect. Would it be better to:
    (1) possibly forget to run "go generate", and thus build an
    invalid/inconsistent output, or
    (2) have the timestamp or hash wizardry automatically notice if it needs
    to "regenerate" the code, where the generator is expressed as a 'filter'.

    ?
    There's no easy way to see that because some generators depend on the
    Internet. eg downloading the latest version of some data and then
    generating based on that.
    What I'm suggesting is only filters without side effects, though I suppose
    a proper implementation would need to add a dependency of the filter
    binary/implementation itself; in case it had been rebuilt.

    --
    Robert Hailey

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Florin Patan at Jul 11, 2015 at 11:43 am

    On Saturday, July 11, 2015 at 8:02:57 AM UTC+2, Robert Hailey wrote:

    On Friday, July 10, 2015 at 6:36:10 PM UTC-5, Egon wrote:


    I think the real question is to this effect. Would it be better to:
    (1) possibly forget to run "go generate", and thus build an
    invalid/inconsistent output, or
    (2) have the timestamp or hash wizardry automatically notice if it needs
    to "regenerate" the code, where the generator is expressed as a 'filter'.

    ?
    There's no easy way to see that because some generators depend on the
    Internet. eg downloading the latest version of some data and then
    generating based on that.
    What I'm suggesting is only filters without side effects, though I suppose
    a proper implementation would need to add a dependency of the filter
    binary/implementation itself; in case it had been rebuilt.
    Hypothetically speaking, how should that be enforced? Also you quickly
    "fixed" the problem with magical "dependency" keyword. And so you now have
    a source code which depends on yet another tool (I'm including go:generate
    in here) to be built. Why do you want to do this to a language which has <
    30 keywords and yet is able to build almost anything developers imagine /
    need.
    Why do you value cosmetics over functionality? Simplicity over ability to
    customize things that you don't need to?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 11, 2015 at 9:46 pm

    On Saturday, July 11, 2015 at 6:43:27 AM UTC-5, Florin Patan wrote:
    Hypothetically speaking, how should [strictly deterministic filters] be
    enforced?
    Rather than enforcement, my thought is to simply not support them... if we
    restrict the filters to pure golang, then their *might* be a way to
    partially enforce that by checking the imports for common bypasses (e.g. to
    make sure they aren't downloading or reading another file), but I don't
    think it's worth the effort to check. I see that as a separate function
    that the current use of "go generate" already expects.

    Put simply, a filter would be *assumed* to vary only based on the input
    file contents, as that is only supported intention.

    Similar to your point, I understand that indeterminism, side effects, and
    hidden dependencies could (IN THEORY) introduce countless fun complications
    to the build process, for example:
    if (time.Seconds() % 200) { string.Replace(line, '+', '/'); }
    ...if in a *filter* could be difficult to diagnose, but (as I indicated
    earlier) is likely to be the first thing to hit the floor when an engineer
    suspects a bad filter, and flattens the whole repo.

    To me, being able to do this may be an indication that it is a sharper or
    more powerful tool (maybe something to complement or surround go).

    ...but yes, point taken, you can shoot yourself in the foot in very
    interesting ways.

    Also you quickly "fixed" the problem with magical "dependency" keyword.
    >

    I haven't dug into go's build structure enough to be specific... (e.g. if
    golang stashes per-file state)... so what I'm presuming is a make-like
    timestamp check. In which case "adding a dependency" would (at a minimum)
    mean that in addition to the current checks [which I would presume to be
    (1) the timestamp of the source file, (2) the timestamp of the object file,
    and (3) the timestamp of the go binary itself] we would also need to (4)
    read the file header (until a non-filter line was read), and (5) test the
    timestamp/existence of each filter binary (in the workspace).... only if
    the object file's timestamp was newer than all the others, could we then
    exclude the file from compilation.

    Which is to say, I suspect it would add a "read header" file operation to a
    process that presently is just a stat() call.

    And so you now have a source code which depends on yet another tool (I'm
    including go:generate in here) to be built.
    This seems like a given, or a bit tautologous, so I presume that I am
    misunderstanding your statement. If the above does not address it, by all
    means, please restate your meaning.

    Why do you want to do this to a language which has < 30 keywords and yet
    is able to build almost anything developers imagine / need.
    At the moment, I am reconsidering this RFE as a separate tool, that would
    be a wrapper around, and delegate 99% of it's work and cli arguments to the
    go complier... using fuse and code borrowed from the the TUP build system
    (to intercept go's file reading, and possibly better track the file-related
    side-effects that you mentioned) while still being 100% go compatible (in
    both language and tool arguments via pass-thru), and being able to add
    versioning at the same time (it will assume that an unspecified go version
    is simply the current/latest).

    Perhaps I'll call it "go anywhere", or "ga" rather than "go". A language
    for babies, not tough enough for "go"... ga ga go go. Get it? Ha!

    Why do you value cosmetics over functionality?
    >

    Cosmetics could be translated as "readability" which I hope to increase,
    and (if anything) this would also *increase* the functionality... so... I
    don't think we are on the same page... :-(

    [Why not value] Simplicity over ability to customize things that you don't
    need to?
    Simplicity has it's place, and flexibility has it's place. Neither is my
    goal.

    What I am trying to do is:
    (1) increase *ORGANIZATION* or the ability to pursue the same, and
    (2) recover wasted/discarded developer effort and talent that would
    otherwise fall away from the go community.

    I appreciate your longer reply, I'll reply to it when I get a bit more time!

    --
    Robert Hailey


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 10, 2015 at 2:24 am
    From the "Can I tweak the go compiler" thread,
    On Thursday, July 9, 2015 at 7:57:26 PM UTC-5, Nigel Tao wrote:

    which (for example)
    is a clearly readable way to mark a file as
    golang-v1-except-for-the-braces...
    golang-v1-accept-for-the-whitespace...
    golang-but-with-c-style-preprocessor, or whatever the author desires.
    I see these examples as costs, not benefits.

    How about "restriction"? "constraint"? "barrier"?

    I doubt such filters would be used by hard-core golang programmers, anyway.

    The whole point of gofmt...
    ...is to automatically filter human-written code (sounds familiar), and
    apply gentle pressure towards conformity. I don't think it's meant to
    restrict freedom.


    http://blog.golang.org/open-source says:
    "Next, refactoring and program analysis. Because Go is for large code
    bases, we knew it would need to support automatic maintenance and
    updating of source code.

    My opinion differs, and this might not have been something that they
    considered at the time.

    IMO, it is more correct to *identify* and *specify*... (like, "this is
    go-v0.9.4 code") and/or automatically filter at compile time (which is what
    I am recommending) than to programmaticly apply sweeping/massive updates to
    large code bases.

    What if, gasp, you needed to go back to the previous version of go for some
    triviality? Ouch!

    "... We also knew that this topic was too large to
    build in directly."

    Yes & no. I agree that the filters, and all these nuisance tweaks don't
    belong in the compiler, but I'm convinced that it would be easy to
    *support* them, without telling everyone to either (1) take a hike, or (2)
    fork go.

    "... In our
    experience attempting automated program changes in other settings, the
    most significant barrier we hit was actually writing the modified
    program out in a format that developers can accept."
    Oddly reminiscent of my comment of golang being a good "intermediate
    language".

    "... In other languages, it's common for different teams to use different
    formatting conventions. If an edit by a program uses the wrong
    convention, it either writes a section of the source file that looks
    nothing like the rest of the file, or it reformats the entire file,
    causing unnecessary and unwanted diffs.

    Go does not have this problem."
    Nor, would it seem, does Go have the associated freedom, such as the
    ability to attritionally migrate to a preferred coding style, or even to
    decide what the coding style ought to be.

    Having golang-v1-except-for-the-braces,
    golang-v1-accept-for-the-whitespace, or the equivalent of
    #define begin { /* Make it look like Pascal! */
    would re-introduce that problem.
    I really like the Pascal example! Some people like to be verbose, or have a
    peculiar need to migrate an aging Pascal program to the new-and-shiny
    golang.... Was that meant as a point against this?

    --
    Robert Hailey


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Jul 10, 2015 at 5:22 am

    On Fri, Jul 10, 2015 at 12:24 PM, Robert Hailey wrote:
    Having golang-v1-except-for-the-braces,
    golang-v1-accept-for-the-whitespace, or the equivalent of
    #define begin { /* Make it look like Pascal! */
    would re-introduce that problem.
    I really like the Pascal example! Some people like to be verbose, or have a
    peculiar need to migrate an aging Pascal program to the new-and-shiny
    golang.... Was that meant as a point against this?
    Yes, the Pascal example is a negative, not a positive.

    Some people like style A, because of reasons A0 and A1. Some people
    like style B, because of reasons B2 and B3. Tabs versus spaces is one
    example.

    Any one individual may strongly prefer their own idiosyncratic style.
    The problem is when Alice and Bob have to work on the same codebase,
    and edit and review each other's code. As a software project grows,
    there may be hundreds of Alices and Bobs. There's certainly hundreds
    listed in https://golang.org/CONTRIBUTORS

    Having some but not all Go programmers say begin instead of { is a
    horrible idea. Please don't encourage it.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 10, 2015 at 9:26 pm

    On Friday, July 10, 2015 at 12:22:35 AM UTC-5, Nigel Tao wrote:
    #define begin { /* Make it look like Pascal! */
    I really like the Pascal example! Some people like to be verbose, or have a
    peculiar need to migrate an aging Pascal program to the new-and-shiny
    golang.... Was that meant as a point against this?
    Yes, the Pascal example is a negative, not a positive.

    Some people like style A, because of reasons A0 and A1. Some people
    like style B, because of reasons B2 and B3. Tabs versus spaces is one
    example.

    Any one individual may strongly prefer their own idiosyncratic style.
    The problem is when Alice and Bob have to work on the same codebase,
    and edit and review each other's code. As a software project grows,
    there may be hundreds of Alices and Bobs. There's certainly hundreds
    listed in https://golang.org/CONTRIBUTORS

    Having some but not all Go programmers say begin instead of { is a
    horrible idea. Please don't encourage it.
    I'm really struggling to understand how this can possibly be "a bad thing",
    or even truly be a thing, when... *by definition*... their is a
    straight-forward and machine readable/executable way to statically apply
    the filters.

    I guess if you found a niche project on github you liked, but the filter
    repo was [re]moved???? But that problem already exists in todays world
    (chasing down libraries and dependencies)... the filter is just one more
    dependency. Like a common (i.e. factored-out) and easily invokable build
    phase (way better than maven plugins).

    You understand that I have in mind only simple, textual modifications; but
    I *REALLY* appreciate the critical thinking of "how far could this go" and
    "what sort of cumulative effect would it have" that you bring to the
    discussion.

    Well, then, let's suppose the worst case... suppose that:
    (1) there is some elite hacker with an arcane perl-like code generator that
    he *loves* to use (call it... "bobx"),
    (2) that nobody else on the planet can read or write this code but himself,
    (3) that it is absolutely mission-critical to a company that your personal
    livelihood depends,
    (4) that this individual was just hit by the preverbial bus (or is
    otherwise unreachable), and
    (5) that you are personally responsible for fixing some bug in this code.

    In the eyes of the present, this might be nearly impossible, and it may
    well be if we continue with the "conventional" language separation or DSL
    theories presented thus far (where you are basically relying on the fact
    that so few people use the "bobx" language that it is statistically
    unlikely that you would run into it in real life). You're pretty much
    toast. Is this sorta what you are imagining?

    If you are correct, and my idea would become so prevalent as to taint
    golang to the point of nuisance or unusability, then this terrible
    situation is actually *NUKED*. The wise programmer (yourself) would only
    need to run a "go flatten" command (or to write a 10-line shell script to
    do the same) that would totally abolish all filters in a project, reverting
    it to equivalent but now-manageable code.

    "Poof"... just like that, golang would go from one of the least flexible
    and quirky languages, to the most flexible nearly "meta-programming"
    language (unbounded, in theory), and then back again *in an instant* if
    needed.

    So, then, who cares how readable the "unfiltered" code is to any particular
    person? It's mechanically reducible to a well defined (and available)
    syntax. In the "worst" case (where everyone is using a convoluted set of
    filters), then those who know pure go become the "elite" programmers... if
    you catch my meaning. In that fictional universe, they would be the one's
    who know "the base code". :-)

    Is it just me, or does the worst case sound... not all that bad?

    --
    Robert Hailey


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Jul 10, 2015 at 10:27 pm
    We can ignore technical problems because they can be fixed.
    First individual style has no significant effect in a scope of a project.
    A single project from a language perspective is not important.
    Go was intended for big projects and collaborations.

    The problems happen in the ecosystem, e.g. if you have projects X, Y, Z, W, Q... Each has their own style, now each wants to contribute a patch to another... X would need to learn 4 different styles along with the code (including the internals of the project). Then each maintainer needs to validate that they are in the correct style and X needs to fix all those style issues. This is what is currently happening in many projects. I have spent 20min to fix different styling issues (I.e. context switch, fix issues, re-run tests, upload changes to review, notify maintainers...). I assume the other party had to have same amount of time wasted. Go is the only language that I know of that doesn't have this problem. Current strictness saves developer time and encourages collaboration.

    For example, JavaScript is one of those examples which shows what happens when it's not actively fought against. You've got tons of different styles, packages, build tools and minor differences. I find it's terrible from the standpoint of getting work done.

    http://cube-drone.com/comics/c/relentless-persistence

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 10, 2015 at 11:25 pm

    On Friday, July 10, 2015 at 5:26:54 PM UTC-5, Egon wrote:
    We can ignore technical problems because they can be fixed.
    First individual style has no significant effect in a scope of a project.
    A single project from a language perspective is not important.
    Go was intended for big projects and collaborations.

    The problems happen in the ecosystem,

    Very good... I'm glad we could narrow the focus to the whole ecosystem...
    although, that sounds a bit weird.

    e.g. if you have projects X, Y, Z, W, Q... Each has their own style, now
    each wants to contribute a patch to another... X would need to learn 4
    different styles along with the code (including the internals of the
    project).

    I'm not convinced that this is true, or perhaps... relevant? Suppose that
    each of the five projects was written by someone of a different native
    language. Bigger issue (learning more languages!). Suppose all those, but
    yours, are hard to read because the authors choose non-descriptive variable
    names ("cow", "dog") or acronyms, or underscores.

    This is either already an issue, or unavoidable.

    Then each maintainer needs to validate that they are in the correct style
    and X needs to fix all those style issues.

    The maintainer has many options, and is not "forced" to do anything, much
    less is he/she subornated to a life of fixing all incoming code for style.
    Maybe the mainter can ignore the patch (maybe someone else will find/like
    the patch), or take your position that the repo must be pure/flat/fmt'd
    golang.

    Yea! Options... freedom!

    This is what is currently happening in many projects. I have spent 20min to
    fix different styling issues (I.e. context switch, fix issues, re-run
    tests, upload changes to review, notify maintainers...). I assume the other
    party had to have same amount of time wasted. Go is the only language that
    I know of that doesn't have this problem. Current strictness saves
    developer time

    Interesting... and I wonder how much help/support/forum-time it has wasted
    arguing about how that format should be, or why it ought to be that way. Or
    what effects it might have on someone who must adhere to multiple enforced
    standards (like an employer, and golang), or what effect the ecosystem has
    for missing developers that *might* have joined the go-gang, or how
    golang's style guide might be seen by other projects in the ecosystem as
    incoming pollution.

    Which is to say... I'm not sure the net effect is a positive one. In fact,
    I'd be a bit surprised if it was.

    ...and encourages collaboration.
    >

    Or more technically, discourages bike-shed-like holy wars on where the
    braces go, tabs-vs-spaces, etc.

    Rest assured, this discouragement would still exist; only it would take the
    form of being 1st-class golang, or 2nd class "filtered" code (which would
    be easy to flatten).

    For example, JavaScript is one of those examples which shows what happens
    when it's not actively fought against. You've got tons of different styles,
    packages, build tools and minor differences. I find it's terrible from the
    standpoint of getting work done.

    http://cube-drone.com/comics/c/relentless-persistence

    This is a perfect point of consideration.

    I agree that the JavaScript situation is awful! It is organically grown
    into a mess, and there is something fundamentally at odds with writing code
    to a quasi-standard that is expected to run any many various
    interpreters/platforms/versions, and expecting it to work across the board,
    and be even the least bit "future proof".

    Relatedly, go 2.x (and subsequent major changes) might face *ALL* the same
    malities discussed heretofor... ecosystem fracturing, onboarding confusion,
    copy/paste breakage, feature buttressing, version mismatches, etc. And I
    think that my filter idea is related to this issue (maybe, mark the file as
    go-1.x via a null filter, which would activate only if running on go-2.x?).

    e.g.
    //!FILTER: golang.org/v/1
    Back to JavaScript.... there *are* javascript formatters/beautifiers... but
    there are also javascript obfuscators... but I'm not really sure
    "formatting differences" is it's primary problem.

    I think that golang would not experience the same effects, simply because
    golang is a compiled language. Oh, would I love a javascript compiler! But
    alas, the same reason that JS cannot be cleaned up (backwards
    compatibility), golang-v2 *can* (escalate deprecation warnings to actual
    build breakage... keeps the language clean).

    What's even better... is that with proper filters, you don't have to tackle
    the whole repo at once, or immediately lose backwards compatibility, when
    go v2 comes around the corner.

    --
    Robert Hailey


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon Elbre at Jul 11, 2015 at 12:01 am
    On Saturday, July 11, 2015, Robert Hailey wrote:
    On Friday, July 10, 2015 at 5:26:54 PM UTC-5, Egon wrote:

    We can ignore technical problems because they can be fixed.
    First individual style has no significant effect in a scope of a project.
    A single project from a language perspective is not important.
    Go was intended for big projects and collaborations.

    The problems happen in the ecosystem,

    Very good... I'm glad we could narrow the focus to the whole ecosystem...
    although, that sounds a bit weird.

    e.g. if you have projects X, Y, Z, W, Q... Each has their own style, now
    each wants to contribute a patch to another... X would need to learn 4
    different styles along with the code (including the internals of the
    project).

    I'm not convinced that this is true, or perhaps... relevant? Suppose that
    each of the five projects was written by someone of a different native
    language. Bigger issue (learning more languages!). Suppose all those, but
    yours, are hard to read because the authors choose non-descriptive variable
    names ("cow", "dog") or acronyms, or underscores.

    This is either already an issue, or unavoidable.
    It is, but it just makes things worse.

    Then each maintainer needs to validate that they are in the correct style
    and X needs to fix all those style issues.

    The maintainer has many options, and is not "forced" to do anything, much
    less is he/she subornated to a life of fixing all incoming code for style.
    Maybe the mainter can ignore the patch (maybe someone else will find/like
    the patch), or take your position that the repo must be pure/flat/fmt'd
    golang.

    Yea! Options... freedom!
    Options are not always beneficial.

    This is what is currently happening in many projects. I have spent 20min
    to fix different styling issues (I.e. context switch, fix issues, re-run
    tests, upload changes to review, notify maintainers...). I assume the other
    party had to have same amount of time wasted. Go is the only language that
    I know of that doesn't have this problem. Current strictness saves
    developer time

    Interesting... and I wonder how much help/support/forum-time it has wasted
    arguing about how that format should be, or why it ought to be that way. Or
    what effects it might have on someone who must adhere to multiple enforced
    standards (like an employer, and golang), or what effect the ecosystem has
    for missing developers that *might* have joined the go-gang, or how
    golang's style guide might be seen by other projects in the ecosystem as
    incoming pollution
    Usually people complain a week, then complain a little less... And then
    they won't notice it.

    Which is to say... I'm not sure the net effect is a positive one. In fact,
    I'd be a bit surprised if it was.

    ...and encourages collaboration.
    Or more technically, discourages bike-shed-like holy wars on where the
    braces go, tabs-vs-spaces, etc.

    Rest assured, this discouragement would still exist; only it would take
    the form of being 1st-class golang, or 2nd class "filtered" code (which
    would be easy to flatten).
    I really mean it encourages collaboration. I personally feel more inclined
    to collaborate and help on a Go project than any other language, because
    there's a lower context switch cost. Some other persons code feels like my
    own code and I can start focusing on the problems at hand.

    For example, JavaScript is one of those examples which shows what happens
    when it's not actively fought against. You've got tons of different styles,
    packages, build tools and minor differences. I find it's terrible from the
    standpoint of getting work done.

    http://cube-drone.com/comics/c/relentless-persistence

    This is a perfect point of consideration.

    I agree that the JavaScript situation is awful! It is organically grown
    into a mess, and there is something fundamentally at odds with writing code
    to a quasi-standard that is expected to run any many various
    interpreters/platforms/versions, and expecting it to work across the board,
    and be even the least bit "future proof".
    Here's an interesting question, why did JS end up like that way? What were
    the major "historical" events that lead to such situation? What were the
    goals of the people making those changes, what were they able to do... Etc.

    Relatedly, go 2.x (and subsequent major changes) might face *ALL* the same
    malities discussed heretofor... ecosystem fracturing, onboarding confusion,
    copy/paste breakage, feature buttressing, version mismatches, etc. And I
    think that my filter idea is related to this issue (maybe, mark the file as
    go-1.x via a null filter, which would activate only if running on go-2.x?).
    Seeing Go Authors commitment to not-breaking things, then there will be a
    smooth transition path to go2. It's something that's not worth worrying
    about at the moment... There are more important things to change in Go
    runtime, packages.

    e.g.
    //!FILTER: golang.org/v/1
    Back to JavaScript.... there *are* javascript formatters/beautifiers...
    For some reason I never get them to work with all different things that JS
    uses. I tried using ES6 syntax with converters... none of the formatters
    worked on that correctly (maybe things are better now)... Finally I gave
    up, and used plain JS because it just works and formatters work, and
    tools work with them.

    but there are also javascript obfuscators... but I'm not really sure
    "formatting differences" is it's primary problem.

    I think that golang would not experience the same effects, simply because
    golang is a compiled language. Oh, would I love a javascript compiler! But
    alas, the same reason that JS cannot be cleaned up (backwards
    compatibility), golang-v2 *can* (escalate deprecation warnings to actual
    build breakage... keeps the language clean).

    What's even better... is that with proper filters, you don't have to
    tackle the whole repo at once, or immediately lose backwards compatibility,
    when go v2 comes around the corner.

    --
    Robert Hailey

       --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/OnSIraKConM/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com
    <javascript:_e(%7B%7D,'cvml','golang-nuts%2bunsubscribe@googlegroups.com');>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 11, 2015 at 4:55 am

    On Friday, July 10, 2015 at 7:01:20 PM UTC-5, Egon wrote:

    Interesting... and I wonder how much help/support/forum-time it has wasted
    arguing about how that format should be, or why it ought to be that way. Or
    what effects it might have on someone who must adhere to multiple enforced
    standards (like an employer, and golang), or what effect the ecosystem has
    for missing developers that *might* have joined the go-gang, or how
    golang's style guide might be seen by other projects in the ecosystem as
    incoming pollution
    Usually people complain a week, then complain a little less... And then
    they won't notice it.
    ...or they simply go away, or they build a clunky generate step, or they
    build their own offshoot language.

    I really mean it encourages collaboration. I personally feel more inclined
    to collaborate and help on a Go project than any other language, because
    there's a lower context switch cost. Some other persons code feels like my
    own code and I can start focusing on the problems at hand.
    It's good to hear your opinion, and I'm glad the consistency helps you.

    For example, JavaScript is one of those examples which shows what happens
    when it's not actively fought against. You've got tons of different styles,
    packages, build tools and minor differences. I find it's terrible from the
    standpoint of getting work done.

    http://cube-drone.com/comics/c/relentless-persistence

    This is a perfect point of consideration.

    I agree that the JavaScript situation is awful! It is organically grown
    into a mess, and there is something fundamentally at odds with writing code
    to a quasi-standard that is expected to run any many various
    interpreters/platforms/versions, and expecting it to work across the board,
    and be even the least bit "future proof".
    Here's an interesting question, why did JS end up like that way? What were
    the major "historical" events that lead to such situation? What were the
    goals of the people making those changes, what were they able to do... Etc.
    That is a good question... was it meant to be rhetorical? Without any
    research I imagine that it is an accumulation of well-intentioned (though
    minimum-impact) feature creep; or maybe more generally... lack of
    organization.

    Relatedly, go 2.x (and subsequent major changes) might face *ALL* the same
    malities discussed heretofor... ecosystem fracturing, onboarding confusion,
    copy/paste breakage, feature buttressing, version mismatches, etc. And I
    think that my filter idea is related to this issue (maybe, mark the file as
    go-1.x via a null filter, which would activate only if running on go-2.x?).
    Seeing Go Authors commitment to not-breaking things, then there will be a
    smooth transition path to go2. It's something that's not worth worrying
    about at the moment... There are more important things to change in Go
    runtime, packages.
    I disagree completely.

    Breakage is a part of versioning, and is key to keeping a project malleable
    and manageable.

    Go seems to suffer from recentism (e.g. always implicitly fetching the
    latest/master branch), which is okay for active development, but is well
    opposed to production stability.

    As I see it, a language can either (1) break stuff, or (2) accumulate
    everything forever.

    Go seems apt to be taking the #1 approach (with bulk code updating, etc),
    and Java seems to be taking the #2 approach.

    Now is the time to consider a language version specification, and not when
    we arrive at the time of go-v3, and all the master branches have run go-fix
    and you are tasked with updating code that you don't even know the go
    version of... or what major versions of it's dependencies it expects, etc,
    etc.

    All you know is that it "sorta worked when it was written", due to the
    recentism.

    e.g.
    //!FILTER: golang.org/v/1
    Back to JavaScript.... there *are* javascript formatters/beautifiers...
    For some reason I never get them to work with all different things that JS
    uses. I tried using ES6 syntax with converters... none of the formatters
    worked on that correctly (maybe things are better now)... Finally I gave
    up, and used plain JS because it just works and formatters work, and
    tools work with them.
    There are a few projects and ideas that could help in the long term...
    "dart" comes to mind, being a versioned language (unlike javascript) with
    it's ability to *compile* dart to output javascript. "Strict mode" might
    have worked (or be useful) if it also added a specification number... :-(

    --
    Robert Hailey

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Jul 11, 2015 at 10:53 am

    On Saturday, 11 July 2015 07:54:59 UTC+3, Robert Hailey wrote:
    On Friday, July 10, 2015 at 7:01:20 PM UTC-5, Egon wrote:


    Interesting... and I wonder how much help/support/forum-time it has
    wasted arguing about how that format should be, or why it ought to be that
    way. Or what effects it might have on someone who must adhere to multiple
    enforced standards (like an employer, and golang), or what effect the
    ecosystem has for missing developers that *might* have joined the go-gang,
    or how golang's style guide might be seen by other projects in the
    ecosystem as incoming pollution
    Usually people complain a week, then complain a little less... And then
    they won't notice it.
    ...or they simply go away, or they build a clunky generate step, or they
    build their own offshoot language.
    And I think it's fine...

    If Go approach restricts your creativity then you might be better served
    with Perl.
    Every language doesn't have to appeal to every-one -- each language has
    their own intentions. If you don't agree with the intentions and the goals
    of then that language is not for you, just use some other language that
    serves you better.

    I really mean it encourages collaboration. I personally feel more inclined
    to collaborate and help on a Go project than any other language, because
    there's a lower context switch cost. Some other persons code feels like my
    own code and I can start focusing on the problems at hand.
    It's good to hear your opinion, and I'm glad the consistency helps you.

    For example, JavaScript is one of those examples which shows what happens
    when it's not actively fought against. You've got tons of different styles,
    packages, build tools and minor differences. I find it's terrible from the
    standpoint of getting work done.

    http://cube-drone.com/comics/c/relentless-persistence

    This is a perfect point of consideration.

    I agree that the JavaScript situation is awful! It is organically grown
    into a mess, and there is something fundamentally at odds with writing code
    to a quasi-standard that is expected to run any many various
    interpreters/platforms/versions, and expecting it to work across the board,
    and be even the least bit "future proof".
    Here's an interesting question, why did JS end up like that way? What
    were the major "historical" events that lead to such situation? What were
    the goals of the people making those changes, what were they able to do...
    Etc.
    That is a good question... was it meant to be rhetorical? Without any
    research I imagine that it is an accumulation of well-intentioned (though
    minimum-impact) feature creep; or maybe more generally... lack of
    organization.
    No, it wasn't rhetorical. I am really interested in what lead to it, I
    believe there are lots of lessons to learn. I'm really interested what were
    the first pieces/projects that started it all and how exactly it happened,
    not just the overview.

    Relatedly, go 2.x (and subsequent major changes) might face *ALL* the same
    malities discussed heretofor... ecosystem fracturing, onboarding confusion,
    copy/paste breakage, feature buttressing, version mismatches, etc. And I
    think that my filter idea is related to this issue (maybe, mark the file as
    go-1.x via a null filter, which would activate only if running on go-2.x?).
    Seeing Go Authors commitment to not-breaking things, then there will be a
    smooth transition path to go2. It's something that's not worth worrying
    about at the moment... There are more important things to change in Go
    runtime, packages.
    I disagree completely.

    Breakage is a part of versioning, and is key to keeping a project
    malleable and manageable.

    Go seems to suffer from recentism (e.g. always implicitly fetching the
    latest/master branch), which is okay for active development, but is well
    opposed to production stability.
    As I see it, a language can either (1) break stuff, or (2) accumulate
    everything forever.

    Go seems apt to be taking the #1 approach (with bulk code updating, etc),
    and Java seems to be taking the #2 approach.
    If a language breaks it will generate a lot of angry/annoyed/confused
    developers. Think of the Python 2/3 split.

    The reason Java is so popular, is that they haven't broken the language.
    It's stable, it's boring, annoying... but it gets the job done.

    And, Go is going for the 2 approach... that's the reason Go as a language
    has so little features. Once you add a feature, you cannot remove it.

    + Egon

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Jul 11, 2015 at 1:57 am

    On Sat, Jul 11, 2015 at 7:26 AM, Robert Hailey wrote:
    I'm really struggling to understand how this can possibly be "a bad thing",
    Have you ever worked on a multi-person software project or
    organization that was big enough to have a style guide? Such guides
    exist for a reason.

    I used to work on a browser plug-in (Gears), and occasionally debugged
    image-related things. The Firefox code is C/C++. The libjpeg code is
    C. The libpng code is C. Each one library is more or less consistent
    in its own house style, but they are different styles. It was jarring
    enough when flipping from browser code to libjpeg code to have all the
    indentation and naming be different. It'd be far worse, though, if
    libjpeg defined its own code filters and libpng defined its own code
    filters, so they weren't even all C but were each their own
    descendent-of-C. It'd be horrible if I was tracking a bug somewhere
    between filtered-Go package foo to filtered-Go package bar, and foo
    and bar each defined their own macro system, but with different
    semantics. Or if I ended up looking in an unfamiliar package baz,
    staring at a simple for loop, and wondering how it's doing something
    impossible, because I didn't look near the top of the file and realize
    that that there's a filter that 'helpfully' defined copy constructors,
    so that a line of code like 'a = b' can actually be a function call.

    or even truly be a thing, when... *by definition*... their is a
    straight-forward and machine readable/executable way to statically apply the
    filters.
    It is not straightforward. There are problems if I'm on Linux and
    you're on Windows (you may not be concerned with non-posix, but plenty
    of Go programmers are). There are problems if my flavor of Linux has
    GNU sed version x.y and your flavor of Darwin has some other sed
    version z ("your code is buggy", "no, it works perfectly on my
    machine"). There are security concerns if running "go build" can exec
    "rm -rf /". Compilation takes longer. It makes automatic updating via
    a tool like gofix impossible.

    That last point is not a small thing. In the lead-up to Go 1, we made
    several breaking changes (see
    https://docs.google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE)
    to the language and to the libraries. It was feasible to do this,
    though, because we could tell everyone "just run gofix" and you're
    done. The solution wasn't to support Go 0.9 code forever.

    If you are correct, and my idea would become so prevalent as to taint golang
    to the point of nuisance or unusability, then this terrible situation is
    actually *NUKED*. The wise programmer (yourself) would only need to run a
    "go flatten" command (or to write a 10-line shell script to do the same)
    that would totally abolish all filters in a project, reverting it to
    equivalent but now-manageable code.
    I disagree with "manageable". m4-style macros are a very simple
    concept, and expanding all the #define'd macros in a C program leads
    to equivalent code, but I definitely wouldn't call editing or
    debugging the resultant "equivalent C code" manageable. GWT compiles
    Java source code to Javascript so that you can run it in a browser,
    but I wouldn't call editing or debugging the resultant "equivalent
    JavaScript code" manageable.

    Even if you had "go flatten", you'd have to "unflatten" if you wanted
    to push a bugfix or an API gofix upstream, and you can't undo sed, let
    alone m4.


    There are certainly benefits to code generation. I use it myself in
    the golang.org/x/image/draw package to create type-specific code paths
    for general purpose image scaling algorithms, despite some of the
    criticisms I gave above applying there too, and the golang.org/x/text
    packages that Marcel and I have written use code generation to convert
    Unicode data tables to statically-buildable Go (running "go build"
    shouldn't issue HTTP requests to unicode.org). But it belongs in a
    separate "go generate" action. It does not belong in the compiler, as
    part of "go build", and it definitely shouldn't be used just because a
    programmer really wants to write their "{" on a line by itself after
    an "if".

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Hailey at Jul 11, 2015 at 5:53 am

    On Friday, July 10, 2015 at 8:57:22 PM UTC-5, Nigel Tao wrote:
    It'd be far worse, though, if
    libjpeg defined its own code filters and libpng defined its own code
    filters, so they weren't even all C but were each their own
    descendent-of-C. It'd be horrible if I was tracking a bug somewhere
    between filtered-Go package foo to filtered-Go package bar, and foo
    and bar each defined their own macro system, but with different
    semantics. Or if I ended up looking in an unfamiliar package baz,
    staring at a simple for loop, and wondering how it's doing something
    impossible, because I didn't look near the top of the file and realize
    that that there's a filter that 'helpfully' defined copy constructors,
    so that a line of code like 'a = b' can actually be a function call.
    Well... that sort of thing is natively supported in C++, so that's might
    just be an occupational hazard...

    I really don't anticipate anyone implementing complex features (like
    generics, or copy constructors), though macros have a similar effect
    (below).

    While I can understand (and support) *not* having that in pure go, I don't
    see that as a reason against filters.
    or even truly be a thing, when... *by definition*... their is a
    straight-forward and machine readable/executable way to statically apply the
    filters.
    It is not straightforward. There are problems if I'm on Linux and
    you're on Windows (you may not be concerned with non-posix, but plenty
    of Go programmers are). There are problems if my flavor of Linux has
    GNU sed version x.y and your flavor of Darwin has some other sed
    version z ("your code is buggy", "no, it works perfectly on my
    machine").

    I'm not sure that can be totally avoided (different compiler versions,
    etc), but that *IS* a good point.

    Would you be more willing to support only pure-golang filters (addressed by
    project path)?

    There are security concerns if running "go build" can exec
    "rm -rf /".

    Yes, and this might be a lot worse than the present state of go (I don't
    know), but the vast majority of (non-golang) projects start with
    "./configure.sh", which could clearly do the same; and "go generate" (which
    would be a build pre-requisite) could probably do this too.

    Compilation takes longer.


    I'm surprised how often this has been brought up.

    Why can "fast vs slow" be more important than "can vs cannot"?

    In any event, the same could also dramatically speed up "go generate" step
    (see below too) because this would be effected by file modification (and go
    generate does not), and go-generate seems to be a pre-build requisite
    anyway.

    It makes automatic updating via
    a tool like gofix impossible [...which] is not a small thing. In the
    lead-up to Go 1, we made
    several breaking changes.
    ...we could tell everyone "just run gofix" and you're
    done. The solution wasn't to support Go 0.9 code forever.
    That might work for early/active development, but does not work in general
    (i.e. the 1.x to 2.x transition, or maintaining 1.x code). It's strange to
    me, because my "go flatten" idea would (in theory) have the same effect as
    go-fix on versioned code, without the obvious translation hazards, and
    might let enthusiasts effectively use newer features in old code... all
    with no additional coding effort (I presume they would make "go fix"
    anyway) and with a smaller go binary (as the fix-it rules would not have to
    be in the binary).
    If you are correct, and my idea would become so prevalent as to taint
    golang
    to the point of nuisance or unusability, then this terrible situation is
    actually *NUKED*. The wise programmer (yourself) would only need to run a
    "go flatten" command (or to write a 10-line shell script to do the same)
    that would totally abolish all filters in a project, reverting it to
    equivalent but now-manageable code.
    I disagree with "manageable". m4-style macros are a very simple
    concept, and

    I was referring to language overall. Is it more manageable to:
    (1) venture into an obscure/unknown/undocumented language & syntax to fix a
    bug, or
    (2) manually translate an obscure/unknown/undocumented language & syntax to
    a "better" language, or
    (3) snap your fingers and make it pure golang.

    My point was just that (all else being equal) the 3rd option is clearly
    superior, whereas the objections predict that it would lead to more of #1 &
    #2.

    ...expanding all the #define'd macros in a C program leads
    to equivalent code, but I definitely wouldn't call editing or
    debugging the resultant "equivalent C code" manageable.

    Then, maybe, "straight forward"? At this point in the argument we are
    already assuming knowledge and preference for pure golang, at the cost of
    repetition (or whatever the macro was intending to help with).

    GWT compiles
    Java source code to Javascript so that you can run it in a browser,
    but I wouldn't call editing or debugging the resultant "equivalent
    JavaScript code" manageable.
    I would agree... but I don't think such "cross-compiling" is comparable to
    minor syntax tweaks & feature additions.

    Even if you had "go flatten", you'd have to "unflatten"...and you can't
    undo sed, let
    alone m4.

    Right. I don't think anyone is advocating that. One way only!

    ...."unflatten" if you wanted
    to push a bugfix or an API gofix upstream,
    If you include the versioning idea, then "go fix" (in it's current form)
    would not really be "needed"... otherwise it could easily be tacked on the
    end of the filter list (if the purpose is to keep old code compilable), or
    easily reimplemented as "increment the version number to the latest version
    and flatten".

    Does that make sense? It's sorta combining two ideas, but the point is that
    they are not incompatible.

    --
    Robert Hailey





    There are certainly benefits to code generation. I use it myself in
    the golang.org/x/image/draw package to create type-specific code paths
    for general purpose image scaling algorithms, despite some of the
    criticisms I gave above applying there too, and the golang.org/x/text
    packages that Marcel and I have written use code generation to convert
    Unicode data tables to statically-buildable Go (running "go build"
    shouldn't issue HTTP requests to unicode.org). But it belongs in a
    separate "go generate" action. It does not belong in the compiler, as
    part of "go build", and it definitely shouldn't be used just because a
    programmer really wants to write their "{" on a line by itself after
    an "if".
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Jul 12, 2015 at 8:51 am

    On Sat, Jul 11, 2015 at 3:53 PM, Robert Hailey wrote:
    Would you be more willing to support only pure-golang filters (addressed by
    project path)?
    No. My disagreement is fundamental. "#define begin {" is as bug, not a
    feature. Eliminating the consistency provided by "gofmt" is a bug, not
    a feature.

    In any event, the same could also dramatically speed up "go generate" step
    (see below too) because this would be effected by file modification (and go
    generate does not), and go-generate seems to be a pre-build requisite
    anyway.
    A key design of "go generate" is that *does not* run every time you or
    anyone else compiles the package, and you don't need to run "go
    generate" (or depend on any other tools) to "go get" it.

    I was referring to language overall. Is it more manageable to:
    (1) venture into an obscure/unknown/undocumented language & syntax to fix a
    bug, or
    (2) manually translate an obscure/unknown/undocumented language & syntax to
    a "better" language, or
    (3) snap your fingers and make it pure golang.
    I choose (0) have all Go programmers use the same programming language: Go.

    "go flatten" is not a solution. Sure, I can snap my fingers, but what
    do I do when I want to submit a patch? I can't submit the generated Go
    code. I could try not submitting it upstream, but then I'm hosed if I
    ever want to pull in a new version, e.g. to fix an urgent security
    bug.

    If you want to invent a new programming language that transpiles to
    Go, that's fine, but that's not Go. If I have to learn your
    idiosyncratic programming language to patch your code, then it's not
    Go code. If I have to learn a dozen idiosyncratic programming
    languages to maintain some software, I'm going to curse the whole,
    long time.

    Some times you need code generation, such as generating .go files from
    a protocol buffer's .proto files, which define an interop protocol
    independent of any one programming language, and those costs above are
    costs you suck up because you need code generation. But if you're
    talking about "minor syntax tweaks & feature additions", then the
    costs are way bigger than the benefits. You don't need code generation
    there, just like I don't need to say "#define func function" whenever
    I dabble with JavaScript these days, even though I really like saying
    "func".

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 6, '15 at 7:56a
activeJul 12, '15 at 8:51a
posts25
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase