Re: [go-nuts] Re: the Dominance of English in Programming Languages

[Michael Jones]

'carcer' is the word. jail/gaol are just johnny-come-lately.

On Sat, May 18, 2019 at 9:43 AM David Riley  wrote:

> On May 18, 2019, at 05:59, ma...@madra.net wrote:
>
> On Saturday, 18 May 2019 00:44:33 UTC+1, Rob 'Commander' Pike wrote:
>>
>> jail is a clear improvement over the ludicrous gaol...
>>
>
> I hadn't actually realised that GAOL vs JAIL was a British vs. US English
> distinction. I thought 'Gaol' was just an archaic spelling of 'Jail', as
> I've only ever come across it in C19th and earlier literature. Even over
> this side of the pond, 'Jail' is used pretty exclusively. Although we
> mostly call it 'Prison' :-)
>
>
> This is OT for the list, but: I think it’s more the latter (an archaism
> rather than a regional distinction; jail is basically universal here
> because we started later).
>
> We do, however, tend to distinguish somewhat between “jail” and “prison”;
> the short version is that jail is temporary holding while awaiting trial,
> while prison is more permanent punitive containment post-sentencing. I’m
> not sure if that distinction exists as much overseas, and in colloquial US
> English, saying that someone is “in jail” is often used for both situations
> (I, myself, enjoy our more colorful slang such as “in the pokey” or “up the
> river”).
>
>
> - Dave
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/A89B99F0-1753-4D8F-81FE-9A6C26A2FDC9%40gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQyzwnGK9zR_KM6w%2Bs5HtHCwM3f6jkXVkZcCsYSbDnG46w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go linker efficiency

[Ian Lance Taylor]

On Sat, May 18, 2019 at 6:01 AM Tong Sun  wrote:
>
> On Saturday, May 18, 2019 at 1:52:43 AM UTC-4, Ian Lance Taylor wrote:
>>
>> On Fri, May 17, 2019 at 9:12 PM Tong Sun  wrote:
>> >
>> > How efficient Go linker is in detecting unused things (e.g., functions) in 
>> > a package during build and remove them from the compiled binary?
>> >
>> > To extremely simplify the case, say
>> >
>> > - I have a package that contains 10 individual functions, and each of them 
>> > will compile to 10K in binary size.
>> > - Then a program calls one single function from such package.
>> >
>> > Will the compiled binary executable be 10K more in size, because of 
>> > calling that one single function, or 100K more?
>> >
>> > I.e., will using a tiny portion of a big package cost me the whole big 
>> > package in compiled binary size, or only the tiny portion that I used?
>>
>> The linker will discard all unused functions and variables, but will
>> not discard unused methods.
>
>
>
> Thanks, Ian
>
> So in other words, if a package A that I'm using is importing 10 other 
> packages, and as long as any of the packages' methods are used within package 
> A's methods, all related methods from those 10 other packages will be 
> compiled & included in the binary executable, right?
>
> E.g., if I'm using a package just for CLI processing, however if the package 
> is doing some funky processing in its methods that use packages of net, 
> net/http, net/url, all related methods from net, net/http, net/url will end 
> up within my binary executable, right?

The details matter, and of course methods are associated with specific
types rather than packages, but, in the general case, yes, that can
happen.

Ian

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU8VTs750TurABx6Hs5saRL%2BRmgvmUQGGb91mv0CdrQRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: the Dominance of English in Programming Languages

[David Riley]

On May 18, 2019, at 05:59, ma...@madra.net wrote:
> 
>> On Saturday, 18 May 2019 00:44:33 UTC+1, Rob 'Commander' Pike wrote:
>> jail is a clear improvement over the ludicrous gaol...
> 
> I hadn't actually realised that GAOL vs JAIL was a British vs. US English 
> distinction. I thought 'Gaol' was just an archaic spelling of 'Jail', as I've 
> only ever come across it in C19th and earlier literature. Even over this side 
> of the pond, 'Jail' is used pretty exclusively. Although we mostly call it 
> 'Prison' :-)

This is OT for the list, but: I think it’s more the latter (an archaism rather 
than a regional distinction; jail is basically universal here because we 
started later).

We do, however, tend to distinguish somewhat between “jail” and “prison”; the 
short version is that jail is temporary holding while awaiting trial, while 
prison is more permanent punitive containment post-sentencing. I’m not sure if 
that distinction exists as much overseas, and in colloquial US English, saying 
that someone is “in jail” is often used for both situations (I, myself, enjoy 
our more colorful slang such as “in the pokey” or “up the river”).


- Dave

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/A89B99F0-1753-4D8F-81FE-9A6C26A2FDC9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] the Dominance of English in Programming Languages

[Andy Balholm]

Just be glad that the American date format caters to (or for!) those Americans 
who say “January two”, not those who (like me) say “January second.” Imagine 
what date-formatting code would look like if ordinal suffixes were required! 
(Jan 1st, Jan 2nd, etc.)

Andy

> On May 18, 2019, at 2:59 AM, ma...@madra.net wrote:
> 
> Tune in same time next week when the topic for discussion will be "Why is the 
> American date format so illogical?"  Although I suspect that, on a mailing 
> list comprised of coders, that one will be less controversial.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/AADF3BFB-5836-4996-A121-655C14165DA2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go linker efficiency

[Tong Sun]

On Saturday, May 18, 2019 at 1:52:43 AM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, May 17, 2019 at 9:12 PM Tong Sun > 
> wrote: 
> > 
> > How efficient Go linker is in detecting unused things (e.g., functions) 
> in a package during build and remove them from the compiled binary? 
> > 
> > To extremely simplify the case, say 
> > 
> > - I have a package that contains 10 individual functions, and each of 
> them will compile to 10K in binary size. 
> > - Then a program calls one single function from such package. 
> > 
> > Will the compiled binary executable be 10K more in size, because of 
> calling that one single function, or 100K more? 
> > 
> > I.e., will using a tiny portion of a big package cost me the whole big 
> package in compiled binary size, or only the tiny portion that I used? 
>
> The linker will discard all unused functions and variables, but will 
> not discard unused methods. 
>


Thanks, Ian 

So in other words, if a package A that I'm using is importing 10 
other packages, and as long as any of the packages' methods are used 
within package A's methods, all related methods from those 10 other 
packages will be compiled & included in the binary executable, right? 

E.g., if I'm using a package just for CLI processing, however if the 
package is doing some funky processing in its methods that use packages of 
net, net/http, net/url, all related methods from net, net/http, net/url 
will end up within my binary executable, right?

thx


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b42b7e71-ad55-496f-9c86-35f479b649e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: the Dominance of English in Programming Languages

[Jakub Labath]

Back in the 90ies someone at Microsoft had the brilliant idea to translate 
Visual Basic that came with the Czech version of Excel into Czech.

So e.g. IF became KDYZ (well it's not Z it's Z with caron - which also was 
a problem if character encoding was not set properly)

The results were that no one was able to re-use any code or documentation 
to learn it. It created numerous problems for IT support as any macros 
written in English were broken.

So in the end rather than creating an army of Czech visual basic 
programmers we were specifically requesting English version of the software 
to replace the Czech ones.

Let's not do that ever again I say.

On Monday, April 29, 2019 at 5:36:37 AM UTC, Chris Burkert wrote:
>
> I recently read an article (German) about the dominance of English in 
> programming languages [1]. It is about the fact that keywords in a language 
> typically are English words. Thus it would be hard for non English speakers 
> to learn programming - argue the authors.
>
> I wonder if there is really demand for that but of course it is weird to 
> ask that on an English list.
>
> I also wonder if it would be possible on a tooling level to support 
> keywords in other languages e.g. via build tags: // +language german
>
> Besides keywords we have a lot of names for functions, methods, structs, 
> interfaces and so on. So there is definitely more to it.
>
> While such a feature may be beneficial for new programmers, to me it comes 
> with many downsides like: readability, ambiguous naming / clashes, global 
> teams ...
>
> I also believe the authors totally miss the point that learning Go is 
> about to learn a language as it is because it is the language of the 
> compiler.
>
> However I find the topic interesting and want to hear about your opinions.
>
> thanks - Chris
>
> 1: 
>
> https://www.derstandard.de/story/2000101285309/programmieren-ist-fuer-jeden-aber-nur-wenn-man-englisch-spricht
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3c016ce9-bc76-4d3a-8549-68d4e1769ea7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: the Dominance of English in Programming Languages

[madra]

On Saturday, 18 May 2019 00:44:33 UTC+1, Rob 'Commander' Pike wrote:
>
> jail is a clear improvement over the ludicrous gaol...
>

I hadn't actually realised that GAOL vs JAIL was a British vs. US English 
distinction. I thought 'Gaol' was just an archaic spelling of 'Jail', as 
I've only ever come across it in C19th and earlier literature. Even over 
this side of the pond, 'Jail' is used pretty exclusively. Although we 
mostly call it 'Prison' :-)

 

> ...with similar favorable positions taken on draft/draught etc.. 
>
...Australia is closer to Britain but sticks with jail and tire...
>

I don't see why the American reforms are necessarily "Favo[u]rable".  In a 
lot of cases, the US spelling actually causes conflict with an existing 
English word, where in British English there is no ambiguity.  You've 
mentioned two already.  TIRE/TYRE and DRAFT/DRAFT. Just think how much 
potential for confusion is avoided by retaining the British English 
spellings in the following:

1: My car was tired so I had it retyred.
2: A sudden draught blew away my draft 

Programme is just something that came out of the blue, from Scotland I 
> believe, replacing the older program again relatively recently


PROGRAM[ME] is another interesting one. As we [sort of!] have both versions 
in British English. Likewise with DISC/DISK

On television we have PROGRAMMES. At the opera or a football [not Soccer!] 
match, you might buy a PROGRAMME but it's generally considered the norm to 
run a PROGRAM on a computer.

In the same vein, you might admire the DISC of the moon or buy the tax DISC 
for your car or play your music on a compact DISC. But you'll have a DISK 
drive in your computer.  

[Though thankfully the abolition of the Tax Disc, the obsolescence of the 
DC and the advent of the SSD is gradually removing this discrepancy]

On Saturday, 18 May 2019 03:32:42 UTC+1, K.S. Bhaskar wrote:
>
> And let's not forget Indian English - between the countries in the Indian 
> Sub-continent (India, Pakistan, Nepal, Bangladesh)...
>

As far as I'm aware the Indian sub-continent officially retains the British 
English spellings. I think you're referring more to regional differences in 
dialect there. That's a whole other can of worms!

Even within the tiny British Isles, there are huge differences in dialects 
of English spoken in different regions. I think people in the US who've 
never visited the British Isles and are only used to hearing that slightly 
artificial and bland-sounding, carefully enunciated "British Accent" that 
most actors from this part of the world seem to adopt when starring in US 
made television and films would probably be shocked to find themselves 
suddenly dumped in the middle of Belfast, Glasgow, Liverpool, Birmingham, 
Dublin, London's East End, etc and trying to follow a conversation amongst 
the locals.

Another thing that I hadn't realised, until I read that article I linked to 
on Noah Webster was that the existing reforms in US spelling were actually 
a much-watered down version of what he had originally intended.  This 
probably explains why they're an odd mixture of [he grudgingly admitted] 
logical changes, such transposing the RE to ER on the end of CENTRE with 
illogical ones such as retaining the C at the beginning, rather than 
replacing it with an S.  

Apparently, if Noah had got his way, it would  have been SENTER but he 
watered down his suggested reforms in the face of public ridicule. Thus 
leaving you Americans with a job only half-done.  Which, I suppose, in a 
way, is why from a British English point of view the differences in 
American English can often seem a bit random and arbitrary.

Tune in same time next week when the topic for discussion will be "Why is 
the American date format so illogical?"  Although I suspect that, on a 
mailing list comprised of coders, that one will be less controversial.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6d791421-5a25-4a28-a643-7761abac5c27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: go modules and ambiguous import, how to fix it?

[Jérôme LAFORGE]

Thx thepudds, the solution with @none has fixed the pb.
I just created the issue https://github.com/golang/go/issues/32128

Le samedi 18 mai 2019 00:13:37 UTC+2, t hepudds a écrit :
>
> Regarding that specific playground error, bradfitz kindly chimed in via a 
> more concise forum:
>
>   
>  
> 
>https://twitter.com/bradfitz/status/1129508420925644802   
>   
>  
> 
>It's because fsnotify doesn't support nacl/amd64p32.
>
>I get the same results locally:
>
>https://play.golang.org/p/IWR9KSQbUnV 
>   
>  
> 
>
> Regards,
> thepudds
> On Friday, May 17, 2019 at 5:50:38 PM UTC-4, t hepudds wrote:
>>
>> I only took a brief look at this, but this seems to be a tricky one.
>>
>> You could try: 
>>   
>>go get github.com/ugorji/go/codec@none
>>
>> That made your example then work for me locally.
>>
>> From the doc (https://golang.org/cmd/go/#hdr-Module_aware_go_get): 
>>   
>>   "The version suffix @none indicates that the dependency should be 
>> removed entirely, downgrading or removing modules depending on it as 
>> needed."
>>   
>> However, then using the resulting go.mod on the playground fails with a 
>> different error:
>>https://play.golang.org/p/EB5T7yuRQSC
>>
>> I did not look into that error, but I am not sure if that is a playground 
>> specific problem with the playground's new module support, or maybe some 
>> package has some NaCl build tag issue, or something else entirely. (It is 
>> fun, though, to add a go.mod to the playground!)
>>
>> It seems viper might be depending on an older problematic version of 
>> github.com/ugorji/go/codec. I would recommend you add your example to 
>> this viper issue here:
>>   https://github.com/spf13/viper/issues/658
>>   
>> The viper project might need to update their go.mod and issue a new viper 
>> release, but not 100% sure.
>>
>> Some additional related discussion in:
>>   https://github.com/gin-gonic/gin/issues/1897
>>   https://github.com/golang/go/issues/29332#issuecomment-448669442
>>   
>> It probably also makes sense to open a clean new issue on the Go issue 
>> tracker with your example, and ask for a clearer diagnostic message or a 
>> simpler solution. (The Go issue mentioned above is closed).
>>
>> Sorry that is not a great answer,
>> thepudds
>>
>> On Friday, May 17, 2019 at 4:52:12 PM UTC-4, Jérôme LAFORGE wrote:
>>>
>>> How can I import this both modules without ambiguous?
>>>
>>> https://play.golang.org/p/YgrEmcTallk
>>>
>>> Thx for your help.
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/de907fbf-842f-44ba-8438-7fb665d8a1b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.