[go-nuts] Re: Generis, yet another Generic go code generator... ;)

[Ecstatic Coder]

Indeed this one is nice too. And quite simple to use compared to several 
other solutions :)

I'm always astonished by the incredible number of code generation solutions 
that Go developers have implemented to emulate strongly-typed generics in 
Go. 

In my own case, I've opted for an all-in-one tool which solved all my needs 
(genericity, free-form macros, conditional compilation, inline HTML 
templating, indentation style, etc) at once, but obviously there are 
already many ways to achieve almost the same result by combining several 
existing tools :)

On Tuesday, March 26, 2019 at 10:44:19 AM UTC+1, Michał Matczuk wrote:
>
> You may be also interested in https://github.com/mmatczuk/go_generics (the 
> credit goes to Google).
>
> With it you can write a generic code that actually compiles and change the 
> types later ex. 
> https://github.com/scylladb/go-set/tree/master/internal/set
>
> W dniu poniedziałek, 25 marca 2019 15:58:03 UTC+1 użytkownik David Skinner 
> napisał:
>>
>> I am very, very, old school, grew up with ASM and Macro Assembly. I 
>> really appreciate this.
>>
>> I prefer to write Go code in a purely idiomatic way but there are times i 
>> just want to finish the job and ship it.
>>
>> Thank you for sharing.
>>
>> On Sunday, March 24, 2019 at 4:23:52 PM UTC-5, Ecstatic Coder wrote:
>>>
>>> Just to inform you that I've just released an first version of *Generis*, 
>>> a lightweight code preprocessor adding the following features to the Go 
>>> language :
>>>
>>>- Generic code definition and instantiation.
>>>- Conditional compilation.
>>>- ERB-like HTML templating.
>>>- Allman to K style conversion.
>>>
>>> https://github.com/senselogic/GENERIS
>>>
>>> It's very similar in function to both Ego and Genny, but implemented as 
>>> a free-form C++-like preprocessor.
>>>
>>> Probably of no use at all for anyone who likes to develop Go code in a 
>>> purely idiomatic way, which obviously I'm not...
>>>
>>>
>>> *Sample*
>>>
>>> package main;
>>> // -- IMPORTS
>>> import (
>>> "html"
>>> "io"
>>> "log"
>>> "net/http"
>>> "strconv"
>>> );
>>> // -- DEFINITIONS
>>>
>>> #define DebugMode
>>> #as true
>>> // ~~
>>>
>>> #define HttpPort
>>> #as 8080
>>> // ~~
>>>
>>> #define WriteLine( {{text}} )
>>> #as log.Println( {{text}} )
>>> // ~~
>>>
>>> #define local {{variable}} : {{type}};
>>> #as var {{variable}} {{type}};
>>> // ~~
>>>
>>> #define DeclareStack( {{type}}, {{name}} )
>>> #as
>>> // -- TYPES
>>>
>>> type {{name}}Stack struct
>>> {
>>> ElementArray []{{type}};
>>> }
>>>
>>> // -- INQUIRIES
>>>
>>> func ( stack * {{name}}Stack ) IsEmpty(
>>> ) bool
>>> {
>>> return len( stack.ElementArray ) == 0;
>>> }
>>>
>>> // -- OPERATIONS
>>>
>>> func ( stack * {{name}}Stack ) Push(
>>> element {{type}}
>>> )
>>> {
>>> stack.ElementArray = append( stack.ElementArray, element );
>>> }
>>>
>>> // ~~
>>>
>>> func ( stack * {{name}}Stack ) Pop(
>>> ) {{type}}
>>> {
>>> local
>>> element : {{type}};
>>>
>>> element = stack.ElementArray[ len( stack.ElementArray ) - 1 ];
>>>
>>> stack.ElementArray = stack.ElementArray[ : len( stack.ElementArray 
>>> ) - 1 ];
>>>
>>> return element;
>>> }
>>> #end
>>> // ~~
>>>
>>> #define DeclareStack( {{type}} )
>>> #as DeclareStack( {{type}}, {{type:PascalCase}} )
>>> // -- TYPES
>>> DeclareStack( string )DeclareStack( int32 )
>>> // -- FUNCTIONS
>>> func HandleRootPage(
>>> response_writer http.ResponseWriter,
>>> request * http.Request
>>> )
>>> {
>>> local
>>> boolean : bool;
>>> local
>>> natural : uint;
>>> local
>>> integer : int;
>>> local
>>> real : float64;

[go-nuts] Generis, yet another Generic go code generator... ;)

[ecstatic . coder]

Just to inform you that I've just released an first version of *Generis*, a 
lightweight code preprocessor adding the following features to the Go 
language :

   - Generic code definition and instantiation.
   - Conditional compilation.
   - ERB-like HTML templating.
   - Allman to K style conversion.

https://github.com/senselogic/GENERIS

It's very similar in function to both Ego and Genny, but implemented as a 
free-form C++-like preprocessor.

Probably of no use at all for anyone who likes to develop Go code in a 
purely idiomatic way, which obviously I'm not...


*Sample*

package main;
// -- IMPORTS
import (
"html"
"io"
"log"
"net/http"
"strconv"
);
// -- DEFINITIONS

#define DebugMode
#as true
// ~~

#define HttpPort
#as 8080
// ~~

#define WriteLine( {{text}} )
#as log.Println( {{text}} )
// ~~

#define local {{variable}} : {{type}};
#as var {{variable}} {{type}};
// ~~

#define DeclareStack( {{type}}, {{name}} )
#as
// -- TYPES

type {{name}}Stack struct
{
ElementArray []{{type}};
}

// -- INQUIRIES

func ( stack * {{name}}Stack ) IsEmpty(
) bool
{
return len( stack.ElementArray ) == 0;
}

// -- OPERATIONS

func ( stack * {{name}}Stack ) Push(
element {{type}}
)
{
stack.ElementArray = append( stack.ElementArray, element );
}

// ~~

func ( stack * {{name}}Stack ) Pop(
) {{type}}
{
local
element : {{type}};

element = stack.ElementArray[ len( stack.ElementArray ) - 1 ];

stack.ElementArray = stack.ElementArray[ : len( stack.ElementArray ) - 
1 ];

return element;
}
#end
// ~~

#define DeclareStack( {{type}} )
#as DeclareStack( {{type}}, {{type:PascalCase}} )
// -- TYPES
DeclareStack( string )DeclareStack( int32 )
// -- FUNCTIONS
func HandleRootPage(
response_writer http.ResponseWriter,
request * http.Request
)
{
local
boolean : bool;
local
natural : uint;
local
integer : int;
local
real : float64;
local
escaped_text,
text : string;
local
integer_stack : Int32Stack;

boolean = true;
natural = 10;
integer = 20;
real = 30.0;
text = "text";
escaped_text = "";

integer_stack.Push( 10 );
integer_stack.Push( 20 );
integer_stack.Push( 30 );

#write response_writer




<%= request.URL.Path %>


<% if ( boolean ) { %>
<%= "URL : " + request.URL.Path %>

<%@ natural %>
<%# integer %>
<%& real %>

<%~ text %>
<%= escaped_text %>
<%= "<%% ignored %%>" %>
<%% ignored %%>
<% } %>

Stack :

<% for !integer_stack.IsEmpty() { %>
<%# integer_stack.Pop() %>
<% } %>


#end
}
// ~~
func main()
{
http.HandleFunc( "/", HandleRootPage );

#if DebugMode
WriteLine( "Listening on http://localhost:HttpPort; );
#end

log.Fatal(
http.ListenAndServe( ":8080", nil )
);
}

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

I've already apologized for my misinterpretation. I want to point out that 
I was 100% sincere in what I was saying. 

Sorry if some of you have taken this for a bold lie, this wasn't absolutely 
meant this way. 

To be completely honest, I still believe what I was saying, even if I admit 
now that this was subject to interpretation.

And I agree that the addition of generics to Go is not especially relevant 
to this discussion on Go vs D.

On Thursday, August 3, 2017 at 3:03:18 PM UTC+1, Ian Lance Taylor wrote:
>
> I don't think this thread is going anywhere useful. 
>
> If people want to discuss technical comparisons between Go and D, that is 
> fine. 
>
> I want to encourage people to stop second guessing motives and 
> comments.  That does not seem helpful. 
>
> Thanks. 
>
> Ian 
>
>
>
> On Thu, Aug 3, 2017 at 6:51 AM,   
> wrote: 
> > Honestly, I didn't know what I was saying was not true. Sincerely. As I 
> > said, I'm a developer, not a psychologist. Interpreting people's thought 
> is 
> > not my job, I'm just a developer, and I haven't even graduated from 
> > university, I just have a bachelor's degree in software development. 
> > 
> > Sorry for my mistake... 
> > 
> > On Thursday, August 3, 2017 at 2:34:01 PM UTC+1, Jan Mercl wrote: 
> >> 
> >> On Thu, Aug 3, 2017 at 3:27 PM  wrote: 
> >> 
> >> > So you mean these 16% thought that Genericity would improve the 
> >> > language, but that it should not be added to the language. 
> >> 
> >> True version: I meant precisely only what I wrote. 
> >> 
> >> -- 
> >> 
> >> -j 
> > 
> > -- 
> > 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...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

Honestly, I didn't know what I was saying was not true. Sincerely. As I 
said, I'm a developer, not a psychologist. Interpreting people's thought is 
not my job, I'm just a developer, and I haven't even graduated from 
university, I just have a bachelor's degree in software development.

Sorry for my mistake...

On Thursday, August 3, 2017 at 2:34:01 PM UTC+1, Jan Mercl wrote:
>
> On Thu, Aug 3, 2017 at 3:27 PM  wrote:
>
> > So you mean these 16% thought that Genericity would improve the 
> language, but that it should not be added to the language.
>
> True version: I meant precisely only what I wrote.
>
> -- 
>
> -j
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

So you mean these 16% thought that Genericity would improve the language, 
but that it should not be added to the language.

Ok, maybe I've misinterpreted the survey, I'm not a psychologist, I 
agree... ;)

Le jeudi 3 août 2017 14:15:31 UTC+1, Jan Mercl a écrit :
>
> On Thu, Aug 3, 2017 at 3:04 PM  wrote:
>
> > I agree that despite genericity is the #1 feature requested by Go 
> developers in Google's last official survey, ...
>
> True version: 16% of the respondents answered "generics" to the question 
> "What 
> changes would improve Go most?"
>
>
> -- 
>
> -j
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

As I said, it's not because something sophisticated exists in a language 
that you have to use it.

It's quite the opposite. But indeed, with Go you don't have the problem, 
because these features were removed from the language to avoid the 
temptation to use them.

I can understand that, because many developers have no enough discipline or 
taste for simplicity, but the unfortunate price to pay is that in the few 
cases where it REALLY helps in making clear code that is easier to 
understand and to maintain, that is sad.

There are many possibilities in D which are not needed in Go, but I don't 
think why you think that genericity (ex: Pool, etc) and 
polymorphism (same method name for a similar argument of a different type) 
are considered as evil.

Properly used, they have their use place in any modern language like Go.

I personally that using interfaces when genericity was a simle and obvious 
solution is what requires more cleverness.

And I'm not saying that using interfaces for this is a bad solution, I'm 
just saying that I don't see the simplicity advantage in it.

Because everytime I have to use interfaces or duplicate implementation for 
such situations, I don't feel at all that Go is helping me implementing 
easier or simpler code.

On Wednesday, August 2, 2017 at 10:47:36 AM UTC+1, Chris Hopkins wrote:
>
>
>
> On Wednesday, 2 August 2017 09:46:08 UTC+1, ecstati...@gmail.com wrote:
>>
>> And btw, this doesn't mean that just because there are genericity and 
>> polymorphism in D, that I must use them.
>>
>> No, but the person reading your code must understand them.  Not only that 
> but they must understand the "clever" way you have used them.
> I came to go for the concurrency, I stayed for the fact that I have yet to 
> come across a piece of code I can't quickly understand.
>
> Every other language I come across that has "advanced" features seems to 
> be an exercise in programmer vanity showing off how clever they are. I 
> spend way more time & brain power trying to reverse engineer someone either 
> showing off their "clever" use of an obscure part of the language than they 
> could ever save with a few less keystrokes.
> The trouble with gerericity and polymorphism and operator overload and all 
> the others are they hide functionality which is great from an academic 
> perpective; when it comes down to debugging what on earth is going wrong 
> they are IME a nightmare.
>
> I think this is why this is turning into a holy war on this list, they are 
> without a doubt great ideas that in theory hide complexity and provide 
> better abstraction and lots of other good things that we should all strive 
> for. The trouble is, in practice many find them to be too powerful for real 
> world use except in certain carefully controlled examples.
>
> I get the impression you want them to make writing code quicker, do you 
> not then share the opinion that in practice for large poorly understood 3rd 
> party systems they make comprehension harder?
>
> Regards
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GO Vs D

[ecstatic . coder]

Ok I understand you now. Maybe I'm biased because I like both languages, 
but I'm not convinced that this example illustrates well Go's simplicity 
compared to D.

For 99% of my *personal* daily use of both languages, very honestly, I've 
never felt that using types, functions, arrays, etc etc was simpler in Go 
compared to D.

Even for more complex stuff like concurrency, I think that both languages 
still remain quite close, despite I think that Go's channel system is the 
best approach to the problem.

On Wednesday, August 2, 2017 at 10:33:03 AM UTC+1, Egon wrote:
>
> The example contained 3 versions, C, D and Go.
>
> function pointer tables aren't that uncommon, maybe the []error part is 
> uncommon
>
> Examples from real world code:
>
> https://github.com/egonelbre/fedwiki/blob/master/action.go#L59
>
> https://github.com/ethereum/go-ethereum/blob/master/crypto/sha3/sha3_test.go#L40
>
> https://github.com/jteeuwen/go-bindata/blob/master/testdata/out/compress-memcopy.go#L205
> https://github.com/golang/net/blob/master/proxy/proxy.go#L57
> https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150
> https://github.com/golang/go/blob/master/src/net/http/server.go#L2391
> https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23
>
> And I've used it in Go, Java, C#, JavaScript, Delphi, C...
>
> The main reason you don't see these one-liners often in C, D et. al. is 
> because they are hard to read.
>
> For common C, C++ examples, see signal and interrupt vector tables.
>
> On Wednesday, 2 August 2017 12:05:43 UTC+3, ecstati...@gmail.com wrote:
>>
>> Still waiting the Go version of this very useful D code...
>>
>> I'm not asking you to browse the web to find to find most complex 
>> declaration you can ever do in D, Go or C++ for instance.
>>
>> I've never used such ridiculous code in my Go/D/C++/Java/C# applications, 
>> and neither will you.
>>
>> I'm just asking you show me how *simple* code in Go will become much 
>> more complicated in D, as this is what you seem to think.
>>
>> And I mean something we will all use all day long (ex: declaring or using 
>> functions/types/arrays/slices/references/loops/etc etc), not the most 
>> complicated code you can come up with.
>>
>> THAT would be useful, and also a fair comparison between both languages.
>>
>> Because from what I see below, I may think you couldn't manage to find 
>> such an example 
>>
>> But maybe I'm wrong, I don't know...
>>   
>> On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote:
>>>
>>> On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:

 For all the common parts with Go (functions, methods, reference 
 classes, strings, arrays, slices, ranges, foreach, etc), honestly I don't 
 know why you say it's simpler in Go.

 Can you show me two examples of code side by side, and tell me "look 
 how much simpler it's with Go's" ?

 Because from what I read, I'm sometimes wondering if you really know 
 that the type declarations in D are MUCH simpler than in C/C++.

>>>
>>> error* (**callbacks)(int);
>>>
>>> Error[] function(int)[][string] callbacks;
>>>
>>> var callbacks map[string]func(int) []error
>>>
>>>
 For instance :

 int[]
 first_array_of_ints,
 second_array_of_ints;

 int[string]
 first_map_of_ints_indexed_by_a_string,
 second_map_of_ints_indexed_by_a_string;

 TYPE
 first_reference_to_an_object_of_this_type,
 second_reference_to_an_object_of_this_type;

 So, with all due respect, how many applications have you already 
 programmed in D before telling me that Go's syntax is so simpler to use 
 and 
 to learn ?

 I agree there are much *less* possibilities in Go, but that doesn't 
 mean it's automatically a simpler language to learn for all the common 
 parts with D. Seriously.

 Because I had to learn both, and at least for a C++/Java/C# programmer 
 like me, D transition was almost immediate, really a matter of hours to 
 become comfortable with the language. Everything was alike, but much 
 simpler and easier than in C++.

 Believe me or not, I've taught programming with D to my two teenagers 
 with D. Really.

 I've chosen it because it was the only strongly-typed language close to 
 Javascript that was really easy to learn, while allowing them to quickly 
 switch to C++, Java or C# later if they wanted to.

 Go is much simpler than C++ too, I agree of course, but for having 
 learned both Go then D, again from the point of view of a former 
 C++/Java/C# programmer like me, I didn't feel that quickly at home with Go 
 than with D, mainly because Go diverged much more from its predecessors 
 than D from a syntactic point of view.

 So, again from a syntactic point of view, I don't think how you can 
 affirm that it's much easier in Go than in D to 

[go-nuts] Re: GO Vs D

[ecstatic . coder]

Still waiting the Go version of this very useful D code...

I'm not asking you to browse the web to find to find most complex 
declaration you can ever do in D, Go or C++ for instance.

I've never used such ridiculous code in my Go/D/C++/Java/C# applications, 
and neither will you.

I'm just asking you show me how *simple* code in Go will become much more 
complicated in D, as this is what you seem to think.

And I mean something we will all use all day long (ex: declaring or using 
functions/types/arrays/slices/references/loops/etc etc), not the most 
complicated code you can come up with.

THAT would be useful, and also a fair comparison between both languages.

Because from what I see below, I may think you couldn't manage to find such 
an example 

But maybe I'm wrong, I don't know...
  
On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote:
>
> On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
>>
>> For all the common parts with Go (functions, methods, reference classes, 
>> strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
>> you say it's simpler in Go.
>>
>> Can you show me two examples of code side by side, and tell me "look how 
>> much simpler it's with Go's" ?
>>
>> Because from what I read, I'm sometimes wondering if you really know that 
>> the type declarations in D are MUCH simpler than in C/C++.
>>
>
> error* (**callbacks)(int);
>
> Error[] function(int)[][string] callbacks;
>
> var callbacks map[string]func(int) []error
>
>
>> For instance :
>>
>> int[]
>> first_array_of_ints,
>> second_array_of_ints;
>>
>> int[string]
>> first_map_of_ints_indexed_by_a_string,
>> second_map_of_ints_indexed_by_a_string;
>>
>> TYPE
>> first_reference_to_an_object_of_this_type,
>> second_reference_to_an_object_of_this_type;
>>
>> So, with all due respect, how many applications have you already 
>> programmed in D before telling me that Go's syntax is so simpler to use and 
>> to learn ?
>>
>> I agree there are much *less* possibilities in Go, but that doesn't mean 
>> it's automatically a simpler language to learn for all the common parts 
>> with D. Seriously.
>>
>> Because I had to learn both, and at least for a C++/Java/C# programmer 
>> like me, D transition was almost immediate, really a matter of hours to 
>> become comfortable with the language. Everything was alike, but much 
>> simpler and easier than in C++.
>>
>> Believe me or not, I've taught programming with D to my two teenagers 
>> with D. Really.
>>
>> I've chosen it because it was the only strongly-typed language close to 
>> Javascript that was really easy to learn, while allowing them to quickly 
>> switch to C++, Java or C# later if they wanted to.
>>
>> Go is much simpler than C++ too, I agree of course, but for having 
>> learned both Go then D, again from the point of view of a former 
>> C++/Java/C# programmer like me, I didn't feel that quickly at home with Go 
>> than with D, mainly because Go diverged much more from its predecessors 
>> than D from a syntactic point of view.
>>
>> So, again from a syntactic point of view, I don't think how you can 
>> affirm that it's much easier in Go than in D to declare and use types, 
>> references, functions, methods, slices, arrays, foreach, and all the common 
>> stuff between both languages.
>>
>> Honestly, no offense intended.
>>
>> On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote:
>>>
>>> But from my personal experience, D is *at least* as easy to learn than 
 Go, if not easier.
>>>
>>>
>>> I seriously doubt, no offense. Go is so small and so intuitive, one can 
>>> argue that there are people out there who knows most of the Go unknowingly 
>>> :) 
>>>
>>> Just the fact that it doesn't break much with the familiar syntax of C#, 
 Java, C++, etc helps a lot in making the transition.

>>>
>>> Go's syntax is very familiar to C, i've never heard it was an issue. The 
>>> only think you must get used to is declarations and i LOVE the Go way. I 
>>> remember the days i was struggling with C's declaration model, the spiral 
>>> rule etc. sure we use typedefs but it rather feels like a hack. 
>>> I can write any declaration no matter how complex it is, with my eyes 
>>> closed in Go. It's so great.
>>>
>>> And genericity and polymorphism are invaluable tools when optimizing 
 code reuse without reducing execution speed.

>>>
>>> I don't ever remember duplicating any code in C. I can't understand how 
>>> people are unable to write reusable code with C, seriously.  Whenever i 
>>> discuss this with a C++ programmer, they immediately share some generic Max 
>>> function that works with int and double.  I admit i use macros in that 
>>> case, but come on it's not even 1% of the serious programming you do in C. 
>>>
>>> If you are a competent C programmer (structured programming in general), 
>>> you know how to write reusable code. 
>>>
>>

-- 
You received this message because you 

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

And btw, this doesn't mean that just because there are genericity and 
polymorphism in D, that I must use them.

Most of the time, I don't even need to use them, like in Go, so I simply 
don't use them.

What I'm saying is that, sometimes, you have to apply a similar function to 
different types for instance, and in this particular case, using genericiy 
OR polymorphism can get the job done quickly and in a cleaner way (DRY 
principle).

That doesn't happen all day long, but I'm occasionally in such situation, I 
really regret there is no native genericity and polymorphism in Go.

Using interfaces and stuff can indeed solve the problem in a way or 
another, but that's far from the simple, easy and obvious way to solve it.

At least that's what I feel each time I have to implement such code. 
Because for web-related development, 

Because despite I prefer D as a general purpose language, I'm still using 
Go to develop server side applications which interact with browsers and 
databases.

Its extensive standard library obviously makes it still the best tool for 
the job, no doubt about it.

On Wednesday, August 2, 2017 at 8:36:18 AM UTC+1, ohir wrote:
>
> On Tue, 1 Aug 2017 05:04:24 -0700 (PDT) 
> ecstati...@gmail.com  wrote: 
>
> > But D also gives you reference classes, genericity, function 
> polymorphism, 
> > conditional compilation, design by contract assertions, compile-time 
> meta 
> > programming, 
>
> All things above to be avoided in _maintainable_ software. 
>
> Mantra: every working line of code is written once by one person 
> then it is read hundreds/thousands of times by dozens of people. 
>
> Go spares your pair, then supervisor, from manually enforcing on 
> you hard local rules: "We use C++ but you are forbidden to use: 
> exceptions, overloading, auto, weak ... ". Go language by itself gives 
> you all that -do-not-use-this-and-that- checks for free ;) 
>
> > and many other features that are severely lacking in Go. 
> Luckily. These and many other features _luckily_ lacking in Go. 
> Something that can't be used also can't be abused. 
>
> From the software maintainer pov Go is both readable and debuggable. 
> In Go one may grasp execution path and functionality from the very 
> fragment of source s/he is reading now. With very few exceptions. 
>
> Throw in any level of meta programming, even simple function overload, 
> and suddenly reader of a fragment of code is forced to read entirety of 
> entangled sources then map it mentally - all that just to grasp importance 
> of that fragment s/he has read a while ago. Rinse and repeat on each level 
> deep. 
>
> Any business gain (man-hour wise) form higher level 'features' is null, 
> void 
> and negative at first bug hunt on production code. More so if said code 
> authors are long gone from the team. Many businesses learnt this 
> hard way and now they know better; now they go for Go. 
>
> > But for your command line or desktop developments, I think D could be 
> much 
> > more appropriate than Go... 
>
> Unless your CLI/desktop is supposed to be easily maintained for years to 
> come. 
>
> PS. If one want some joy and entertainment off writing, one may go for 
> Racket [https://racket-lang.org/]. Every program in it sooner than later 
> evolves into separate language of its own. Language only author can 
> understand. Even if just for a while ;). 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GO Vs D

[ecstatic . coder]

For all the common parts with Go (functions, methods, reference classes, 
strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
you say it's simpler in Go.

Can you show me two examples of code side by side, and tell me "look how 
much simpler it's with Go's" ?

Because from what I read, I'm sometimes wondering if you really know that 
the type declarations in D are MUCH simpler than in C/C++.

For instance :

int[]
first_array_of_ints,
second_array_of_ints;

int[string]
first_map_of_ints_indexed_by_a_string,
second_map_of_ints_indexed_by_a_string;

TYPE
first_reference_to_an_object_of_this_type,
second_reference_to_an_object_of_this_type;

So, with all due respect, how many applications have you already programmed 
in D before telling me that Go's syntax is so simpler to use and to learn ?

I agree there are much *less* possibilities in Go, but that doesn't mean 
it's automatically a simpler language to learn for all the common parts 
with D. Seriously.

Because I had to learn both, and at least for a C++/Java/C# programmer like 
me, D transition was almost immediate, really a matter of hours to become 
comfortable with the language. Everything was alike, but much simpler and 
easier than in C++.

Believe me or not, I've taught programming with D to my two teenagers with 
D. Really.

I've chosen it because it was the only strongly-typed language close to 
Javascript that was really easy to learn, while allowing them to quickly 
switch to C++, Java or C# later if they wanted to.

Go is much simpler than C++ too, I agree of course, but for having learned 
both Go then D, again from the point of view of a former C++/Java/C# 
programmer like me, I didn't feel that quickly at home with Go than with D, 
mainly because Go diverged much more from its predecessors than D from a 
syntactic point of view.

So, again from a syntactic point of view, I don't think how you can affirm 
that it's much easier in Go than in D to declare and use types, references, 
functions, methods, slices, arrays, foreach, and all the common stuff 
between both languages.

Honestly, no offense intended.

On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote:
>
> But from my personal experience, D is *at least* as easy to learn than Go, 
>> if not easier.
>
>
> I seriously doubt, no offense. Go is so small and so intuitive, one can 
> argue that there are people out there who knows most of the Go unknowingly 
> :) 
>
> Just the fact that it doesn't break much with the familiar syntax of C#, 
>> Java, C++, etc helps a lot in making the transition.
>>
>
> Go's syntax is very familiar to C, i've never heard it was an issue. The 
> only think you must get used to is declarations and i LOVE the Go way. I 
> remember the days i was struggling with C's declaration model, the spiral 
> rule etc. sure we use typedefs but it rather feels like a hack. 
> I can write any declaration no matter how complex it is, with my eyes 
> closed in Go. It's so great.
>
> And genericity and polymorphism are invaluable tools when optimizing code 
>> reuse without reducing execution speed.
>>
>
> I don't ever remember duplicating any code in C. I can't understand how 
> people are unable to write reusable code with C, seriously.  Whenever i 
> discuss this with a C++ programmer, they immediately share some generic Max 
> function that works with int and double.  I admit i use macros in that 
> case, but come on it's not even 1% of the serious programming you do in C. 
>
> If you are a competent C programmer (structured programming in general), 
> you know how to write reusable code. 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GO Vs D

[ecstatic . coder]

Indeed a language that offer much less tools is much easier to learn, and 
also to master.

But from my personal experience, D is *at least* as easy to learn than Go, 
if not easier.

Just the fact that it doesn't break much with the familiar syntax of C#, 
Java, C++, etc helps a lot in making the transition.

And genericity and polymorphism are invaluable tools when optimizing code 
reuse without reducing execution speed.

I know that everything can be done with interfaces, but unfortunately they 
run slower (according to the Golang website) than direct calls to 
type-specific code, and most of the time even with interface you have to 
manually adapt the implementation anyway.

And copy/pasting then adapting manually the code is dumb and error proof. 
If you have always managed to avoid doing that for your Go applications, 
then I'm happy for you, this means you are much smarter than me.

On Tuesday, August 1, 2017 at 1:54:45 PM UTC+1, Doğan Kurt wrote:
>
> But D also gives you reference classes, genericity, function polymorphism, 
>> conditional compilation, design by contract assertions, compile-time meta 
>> programming, and many other features that are severely lacking in Go.
>>
>
> That's the biggest reason i love Go, *except maybe ken thompson :)*
>
>
> *- A language that doesn’t have everything is actually easier to program 
> in than some that do.  Dennis M. Ritchie*
>
>
> *- Do Less. Enable More. Russ Cox*
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GO Vs D

[ecstatic . coder]

I've written only what I know for sure, i.e. that Go is used a lot for 
server side applications.

I didn't know it was also used a lot on the client side for mobile and 
desktop GUI applications, sorry for my ignorance.
On Tuesday, August 1, 2017 at 1:54:45 PM UTC+1, Doğan Kurt wrote:
>
> But D also gives you reference classes, genericity, function polymorphism, 
>> conditional compilation, design by contract assertions, compile-time meta 
>> programming, and many other features that are severely lacking in Go.
>>
>
> That's the biggest reason i love Go, *except maybe ken thompson :)*
>
>
> *- A language that doesn’t have everything is actually easier to program 
> in than some that do.  Dennis M. Ritchie*
>
>
> *- Do Less. Enable More. Russ Cox*
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

D being rather unpopular (#23 at the TIOBE index of July 2017) at the 
moment compared to Google's Go, which is impressively climbing the charts 
at high speed, then I think we shouldn't worry too much about D's 
decline... ;)

On Tuesday, August 1, 2017 at 10:18:21 AM UTC+1, Russel Winder wrote:
>
> On Mon, 2017-07-31 at 12:21 -0500, John McKown wrote: 
> > 
> […] 
> > An excellent approach to all languages. If someone doesn't like "go", 
> > then use a different language. Or be like some people and invent your 
> own 
> > to address the perceived problems with all the other languages in 
> existence. 
> > 
>
> Once a programming language goes into production and invokes "backward 
> compatibility" it rarely improves by evolution. cf. Fortran, Java. 
> Invariably, 
> improvement in programming happens by new programming languages arriving 
> on 
> the scene and being picked up (or not). Each programming language that 
> gains 
> traction invariably goes into decline as new languages pop up to replace 
> it. 
>
> But remember COBOL, FORTRAN, Fortran, and C still have large codebases in 
> place even though very few people would consider writing new code in those 
> languages. Go, Rust, D, etc. will travel the same path after their period 
> of 
> being very popular. 
>
> > 
> -- 
> Russel. 
> = 
>
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russ...@ekiga.net 
>  
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk 
>  
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GO Vs D

[ecstatic . coder]

I come back to this forum I read a long time ago, because after having used 
Go for several projects, I've recently switched to D, and I wanted to share 
my opinion on it.

First, if I can make a caricatural comparison, i'd like to say that to me, 
Go is just a "much better C", while D is instead a "much better C++".

I mean, like Go, D has also an incredibly fast compilation, a GC, and it 
provides very convenient maps, arrays, strings, slices, foreach, ranges, 
concurrency, etc, all at the language level.

But D also gives you reference classes, genericity, function polymorphism, 
conditional compilation, design by contract assertions, compile-time meta 
programming, and many other features that are severely lacking in Go.

Moreover, with D you can really go low-level like in C if you need to. It 
*also* has C-like pointers, structs, inline assembly, etc, if you want to 
use C or C++ functions and data structures without wrapper code.

Finally, what's really nice is that D provides all these features through a 
very simple, classic and convenient syntax, which make it quite easy to 
port your code from C, C++, Java, C#, Go, etc.

Of course, Go, as a web-centric language, has obviously a much more 
complete standard library when it comes to web development. 

So if you want to interact with servers, databases and anything like that, 
Go may remain the best alternative.

But for your command line or desktop developments, I think D could be much 
more appropriate than Go...

On Friday, October 11, 2013 at 9:54:23 PM UTC+1, Rohit Yadav wrote:
>
> Hi,
>
> Since the last active message on this thread a lot of progress was 
> achieved by both the projects, would anyone like to share latest 
> comparisons between the two languages and the ecosystem around it (tooling, 
> usage, adoption, etc.)?
> We see that Go is nowadays used for not just writing servers but general 
> programs as well, how does D scale to that and if Andrei and others can 
> update us on D with respect to areas where Go excels such as ease of 
> writing concurrent software, tooling, ease of learning the language and its 
> hackability.
>
> Regards,
> Rohit
>
> On Saturday, 14 August 2010 06:09:36 UTC+5:30, Andrei Alexandrescu wrote:
>>
>> On Aug 13, 3:00 pm, Ian Lance Taylor  wrote: 
>> > Andrei Alexandrescu  writes: 
>> > >http://www.informit.com/articles/printerfriendly.aspx?p=1609144 
>> > 
>> > Thanks.  As you know, this approach is clearly different from the one 
>> in 
>> > Go, which is a transfer of ownership model, where the transfer of 
>> > ownership is enforced only by convention.  And, of course, Go doesn't 
>> > use the type system, which follows Go's general guideline of keeping 
>> the 
>> > type system light weight. 
>>
>> I understand. So what we have now is: 
>>
>> (1) Pass-by-bitblt through channels for value types (i.e. no 
>> indirections, which means dynamic arrays are unduly shared). There is 
>> no checking that a value type being passed actually does not have 
>> indirections. 
>>
>> (2) Pass of ownership by unchecked convention for data with 
>> indirections. 
>>
>> (3) Everything else is undefined. 
>>
>> If that's true, parts 1 and 2 are of limited expressiveness but it's 
>> part 3 that's really problematic, and I'm not sure a putative 
>> programmer understands the implications. Essentially that means even 
>> lock-based programming relies on implementation-level vagaries because 
>> without a memory model the compiler and the processor are relatively 
>> free to hoist data around rather freely. We're back to the reorderings 
>> hell often showcased as motivators of Java's and C++0x's memory 
>> models. 
>>
>> > >> You're quite right: Go does permit data races, and does currently 
>> rely 
>> > >> only on convention to avoid them.  Go's advantage over C++, and it 
>> is a 
>> > >> significant advantage, is that the rules for valid sharing are 
>> fairly 
>> > >> simple, and the language makes it much easier to do valid sharing. 
>> > 
>> > > How does Go simplify the rules for valid sharing? Far as I can tell 
>> it 
>> > > can only simplify if it renders undue aliasing undefined. Does Go 
>> have 
>> > > something equivalent to Java's volatile and C++0x's atomic? 
>> > 
>> > The rules for valid sharing are encapsulated in the slogan "don't 
>> > communicate by sharing memory; instead, share memory by communicating." 
>> > That is, always use channels to communicate between goroutines.  Always 
>> > ensure that a single goroutine owns shared data, and use an explicit 
>> > channel send to transfer ownership to a different goroutine. 
>> > 
>> > This approach can be used in other languages also, of course; the 
>> > advantage I see in Go is that the language makes it simple and easy. 
>>
>> A memory model may as well be the perfect example where simplicity is 
>> your enemy - not defining one is indeed simple, but has huge costs to 
>> the user in one or more of correctness, 

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

The irony is that I don't even use the automatic semi-colon insertion 
feature. 

I'm used to add them manually anyway, even in Go, as whenever possible I 
tend to program in a less idiomatic way (for loops, semi-colons, etc) which 
allows me to easily port substantial parts of my code from one language to 
another.

For instance, several tools on my github account were initially implemented 
using Node.js, but I could very quickly port them to D.

But I know that this particular inclination makes me belong to an 
ultra-minority, once again... ;)

On Monday, July 31, 2017 at 3:18:09 AM UTC+1, Ian Lance Taylor wrote:
>
> On Sat, Jul 29, 2017 at 10:36 AM,   
> wrote: 
> > 
> > ... 
> > 
> > But as Gofmt can ALREADY enforces this common coding style, and can be 
> run 
> > at any time, including before committing code on the depots, why should 
> it 
> > be enforced by the COMPILER too ? 
> > 
> > Really, that's the one particular engineer decision I regret. Just one. 
> But 
> > that's a big one. Because sometimes, almost ENTIRE teams prefer the 
> Allman 
> > style. That's not just a personal affair. All that because maybe 2 or 3 
> > languages designers have decided so, moreover to make it easy to 
> > automatically add the semi-colons. 
> > 
> > And it doesn't even work well, we are now force to put a useless comma 
> after 
> > the last parameter of a function to be allowed to split the arguments on 
> > several lines. Please don't insult me by telling there wasn't any other 
> > possible solution. 
> > 
> > For instance, in Javascript, the semi-colon are also optional, but the 
> > compiler lets you use whatever coding style you want. 
>
> I'll note that there is a lot of discussion on the web about problems 
> with semicolons in Javascript.  When we were discussing the 
> possibility of a lexical semicolon insertion rule shortly after the Go 
> open source release, Javascript was considered to be an example of how 
> not to do it. 
>
> Historically speaking, gofmt came before lexical semicolon insertion. 
> The existence of gofmt made it possible to seriously consider lexical 
> semicolon insertion.  Implementing it did require, yes, that you must 
> put a comma after a parameter name in order to split a line and, yes, 
> that you must put the '{' on the same line as the function definition 
> or if/for/switch statement, etc.  We considered that to be an 
> acceptable drawback to get a simple rule, knowing that gofmt would 
> handle all such issues anyhow. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: D vs Go

[ecstatic . coder]

I suggest you to look at the official D website, but if you want a 
caricatural comparison, let's say that Go is a much better C, while D is a 
much better C++.

Like Go, D has also an incredibly fast compilation, a GC, and it provides 
very convenient maps, arrays, strings, slices, foreach, ranges, 
concurrency, etc, all at the language level.

And it adds reference classes, genericity, polymorphism, compile-time meta 
programming, functional programming, and many other useful features that 
make programming with it an incredibly enjoyable experience.

And you can go low-level too. It *also* has C-like pointers, structs, 
inline assembly, etc if you really want, for instance to use C or C++ 
functions and data structures.

All that is available through a very simple C/C#-like syntax, which make it 
easy transitioning from C, C++, Java, C#, Go, etc.

That said, Go has clearly a much more complete standard library when it 
comes to web development. If you want to interact with servers, databases 
and anything like that, Go remains the best alternative I know.

Don't forget that D is a general purpose language developed by a few 
individuals on their free time, while Go is a web-focused language 
financially supported by Google.

So if you are risk averse, my advice would still to use Go for server side 
development, and D for command line tools and desktop applications.

On Sunday, July 30, 2017 at 5:27:00 PM UTC+1, me wrote:
>
>
>
> On Sunday, July 30, 2017 at 6:24:44 AM UTC-6, ecstati...@gmail.com wrote:
>>
>>
>> Moreover, it's because of these little "details" that I looked for an 
>> alternative, and started using D, which is a kind of "Go done well" for me, 
>> even if I clearly see that as a community project without any financial 
>> funding, D will never be able to compete on the same grounds as Go.
>>
>
> Please explain why D was done right, and the reasons D is better for 
> programming than Go.
>
> I was interested in D, but lost interest since virtually no one is using 
> it and there fore is risky (I know there are some using it, but, 
> virtually...I said ;-))
>
> Also there is more than one D, TutorialD also. But I'm pretty sure you 
> mean Digital Mars D
>
> (This starts a new thread with a different subject now ;-))
>
> . 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

Anyway, even if I was a bit angry by the "ad personam" attack, I want to 
say that  even if the Go compiler maintainers don't or can't fix this 
because of their semi-colon insertion algorithm, it's not a problem for me 
to use Go as it is.

As I develop in Helix, now I don't care about that anymore, and this 
language only exists because Go is such a fantastic compilation target for 
language compilers and preprocessors.

As I said, I'm really grateful to Google and its management to have 
open-sourced their internal technology, which I appreciate a lot, even if I 
don't agree with every decision they made.

I know why they did it, as they have explained it (hiring young engineers, 
etc), and I understand their decision, even if I regret they didn't make it 
optional for the rest of the planet.

Moreover, it's because of these little "details" that I looked for an 
alternative, and started using D, which is a kind of "Go done well" for me, 
even if I clearly see that as a community project without any financial 
funding, D will never be able to compete on the same grounds as Go.

So again, thanks to Google for their great job with Go, and also for their 
nice open-source policy. 

On Sunday, July 30, 2017 at 9:36:26 AM UTC+1, ohir wrote:
>
> On Sat, 29 Jul 2017 16:56:05 -0700 (PDT) 
> ecstati...@gmail.com  wrote: 
>
> > Anyway, thanks for the fun. Where is the popcorn ? LOL 
>
>Q.E.D. 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

Personally I'd prefer a simple compiler option :)

On Sunday, July 30, 2017 at 12:50:55 AM UTC+1, Hrobjartur Thorsteinsson 
wrote:
>
> Dude, you are right. This confusing coding style with syntax in Go can be 
> fixed by forking and applying a rediculously small patch. Jeez, lets stop 
> complaining as u rightfully suggested.
>
> 29. júl. 2017 10:43 e.h. skrifaði "Wojciech S. Czarnecki" <
> oh...@fairbe.org >:
>
>> On Sat, 29 Jul 2017 10:36:42 -0700 (PDT)
>> ecstati...@gmail.com  wrote:
>>
>> [APM]
>> [Ad Personam mode on, I humbly apologize to bystanders]
>>
>> Enough is enough!
>>
>> > Really, that's the one particular engineer decision I regret. Just one. 
>> But
>> > that's a big one. Because sometimes, almost ENTIRE teams prefer the 
>> Allman
>> > style. That's not just a personal affair.
>>
>> This is yours strictly personal affair. Through this all thread you 
>> *demand*
>> from the go team and the community to design, write and maintain tools for
>> functionality *only you personally* deem important. More - you *demand* 
>> from
>> us __thousands and millions of hours of compile time__ because *you* want
>> your tastes satisfied.
>>
>> Stop whining and *do instrument* your editor with s/(\S\s*)}\s*$/\1\n}/.
>> In C++ or java or ecmascript or...
>> It is You who need this style so make your environment allow it. Its easy.
>> (It was common in times we were paid by LOC but had 22 usable screen
>> lines).
>>
>> If above instrumentation is beyond your allman-loving team competence why
>> and *HOW* do you want to program anything usable to others?
>>
>> > All that because maybe 2 or 3 languages designers have decided so,
>> > moreover to make it easy to automatically add the semi-colons.
>>
>> They gave it to you for free. It is open source. So
>>
>>  *FORK*
>>
>>   Tailor to your tastes! Make ponies dance!
>>
>>  > And it doesn't even work well, we are now force to put a useless comma
>> > after the last parameter of a function to be allowed to split the 
>> arguments
>> > on several lines. Please don't insult me by telling there wasn't any 
>> other
>> > possible solution.
>>
>> *FORK* !!! Do better.
>>
>> [\APM]
>>
>> --
>> Wojciech S. Czarnecki
>>  << ^oo^ >> OHIR-RIPE
>>
>> --
>> 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/rzLzp_Z74ik/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

LOL ;)

On Sunday, July 30, 2017 at 9:36:26 AM UTC+1, ohir wrote:
>
> On Sat, 29 Jul 2017 16:56:05 -0700 (PDT) 
> ecstati...@gmail.com  wrote: 
>
> > Anyway, thanks for the fun. Where is the popcorn ? LOL 
>
>Q.E.D. 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

Ok, I can agree with you.

But the only problem is that often, the reason why many developers *decide* 
to switch from the K to Allman at some point in their career (like me) is 
because they think that sparing these few lines in code height to the price 
of breaking the blocks natural alignment actually hurts the code 
readability.

If there are roughly as many Allman style coders as K style coders, this 
means that there are also roughly as many people who think that K harms 
the readability by breaking the block alignment than people who think it 
improves the readability by compacting the code. 

Even if you think this is questionable, please at least respect the half of 
us who think that readability is improved by this alternative style.

Because, if this style had no readability advantage for us, why would we 
want so much to use it, you really think we are that stupid, seriously ?

On Saturday, July 29, 2017 at 9:14:50 PM UTC+1, Jan Mercl wrote:
>
> On Sat, Jul 29, 2017 at 7:36 PM  
> wrote:
>
> > But as Gofmt can ALREADY enforces this common coding style, and can be 
> run at any time, including before committing code on the depots, why should 
> it be enforced by the COMPILER too ?
>
> Let me pick just one misconception. The compiler does not care about 
> formatting style at all - because it cannot see it! Token sequences have no 
> style as they contain no white space or any other kind of token separators. 
> It's just tokens. All the way down.
>
> The specification prescribes how the source code text is transformed into 
> the token sequence the compiler only cares about. It's different in 
> details, but conceptually it's just a transformation stage in the sense of 
> what the specification of the, for example, C language prescribes.
>
> You may dislike the specification, but you can hardly argue it's not well 
> thought out and reasonable as a trade-off between mandatory semicolons (pre 
> Go 1 had them) and almost no need to write them in exchange for adjusting 
> to the implications and/or costs of that comfort.
>
> If Go changed its specification such that the left brace of a statement 
> block must be on its own line, it'll take me probably just a few minutes to 
> adapt and forget about it completely, because it's such an unimportant 
> detail compared to what I love about Go. Why some others cannot do the same 
> is beyond my comprehension, but that's by definition my fault, admitted.
>
> -- 
>
> -j
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

Without apologies, I am linking to the official Google survey... LOL

What changes would improve Go most ?
#1. 572 (16%) generics

(https://blog.golang.org/survey2016-results)

Whoops ;)

So you mean that 16% of us are so stupid we don't want to copy paste the 
code and adjust it, or use slowinterfaces ?

Btw, just a silly question, but I wrongly assumed that a direct call to 
instantiated type-specific code was much faster than an indirect call to an 
interface. 

So you mean that  the following code is much faster than type-specific 
code, right, and therefore this is the adviced way to format variables ?

var i interface{} = 23
fmt.Printf("%v\n", i)

(https://golang.org/pkg/fmt/)

OMG, that's really great, thanks !!! Because it was quite error prone to 
copy-paste the repeated code and adjust it manually. Thank you so much, you 
made my day :)

I was so stupid, thanks for showing my the right way to optimize reused 
code.

On Sunday, July 30, 2017 at 12:02:04 AM UTC+1, Shawn Milochik wrote:

Without apologies, I am linking to a post I wrote seconds ago regarding 
> generics. 
>
> It applies here equally. Perhaps more so, since the percentage of 
> brace-complainers is a tiny fraction of the percentage of generics-whiners:
> https://groups.google.com/d/msg/golang-nuts/hQiZsd1ZRdA/DSgV7CX7BwAJ
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

LOL, obviously you haven't read my previous posts ;)

Ok, I'll repeat it then, no problem. I'm actually the developer of an open 
source preprocessor (Genesis) that can also be used to add Allman style and 
pseudo-generics to Go.

And internally I also use a templating language similar to PHP (Helix) 
which emit Go code in a way similar to my Phoenix language.

Anyway, thanks for the fun. Where is the popcorn ? LOL

On Saturday, July 29, 2017 at 11:43:52 PM UTC+1, ohir wrote:
>
> On Sat, 29 Jul 2017 10:36:42 -0700 (PDT) 
> ecstati...@gmail.com  wrote: 
>
> [APM] 
> [Ad Personam mode on, I humbly apologize to bystanders] 
>
> Enough is enough! 
>
> > Really, that's the one particular engineer decision I regret. Just one. 
> But 
> > that's a big one. Because sometimes, almost ENTIRE teams prefer the 
> Allman 
> > style. That's not just a personal affair. 
>
> This is yours strictly personal affair. Through this all thread you 
> *demand* 
> from the go team and the community to design, write and maintain tools for 
> functionality *only you personally* deem important. More - you *demand* 
> from 
> us __thousands and millions of hours of compile time__ because *you* want 
> your tastes satisfied. 
>
> Stop whining and *do instrument* your editor with s/(\S\s*)}\s*$/\1\n}/. 
> In C++ or java or ecmascript or... 
> It is You who need this style so make your environment allow it. Its easy. 
> (It was common in times we were paid by LOC but had 22 usable screen 
> lines). 
>
> If above instrumentation is beyond your allman-loving team competence why 
> and *HOW* do you want to program anything usable to others? 
>
> > All that because maybe 2 or 3 languages designers have decided so, 
> > moreover to make it easy to automatically add the semi-colons. 
>
> They gave it to you for free. It is open source. So 
>
>  *FORK* 
>
>   Tailor to your tastes! Make ponies dance! 
>
>  > And it doesn't even work well, we are now force to put a useless comma 
> > after the last parameter of a function to be allowed to split the 
> arguments 
> > on several lines. Please don't insult me by telling there wasn't any 
> other 
> > possible solution. 
>
> *FORK* !!! Do better. 
>
> [\APM] 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

Sorry to repeat myself, but I think I wasn't clear enough, as many people 
on this forum still don't understand my point at all. 

Google, as ANY company, MUST force its employees to use exactly the same 
standards.

I've done the same with the engineers in my company. And they used my own 
code formatting tool.

And I'm glad to Google that their management decided to let us use their 
compiler and their other internal tools, including Gofmt.

But as Gofmt can ALREADY enforces this common coding style, and can be run 
at any time, including before committing code on the depots, why should it 
be enforced by the COMPILER too ?

Really, that's the one particular engineer decision I regret. Just one. But 
that's a big one. Because sometimes, almost ENTIRE teams prefer the Allman 
style. That's not just a personal affair. All that because maybe 2 or 3 
languages designers have decided so, moreover to make it easy to 
automatically add the semi-colons.

And it doesn't even work well, we are now force to put a useless comma 
after the last parameter of a function to be allowed to split the arguments 
on several lines. Please don't insult me by telling there wasn't any other 
possible solution.

For instance, in Javascript, the semi-colon are also optional, but the 
compiler lets you use whatever coding style you want.

You can then use a tool like Gofmt to fix it automatically. There is one 
such tool on my github account btw.

On Friday, July 28, 2017 at 6:14:01 AM UTC+1, Ian Lance Taylor wrote:
>
> On Thu, Jul 27, 2017 at 6:35 PM, Hrobjartur Thorsteinsson 
>  wrote: 
> > 
> > Do you realize that the Go lang devs themselves are not actually in 
> > agreement about the original motivations for constraining the language 
> in 
> > this way. Some quote some one true K style, while it is in fact this 
> is 
> > not K style, other quote some dubious statistics on programmer habbits 
> > with code blocks, and yet other quote that it's just to help the Go-lang 
> > compiler meta-compile statement delimiters ";".  All this confusion and 
> > effort for nothing, and all the while ignoring some real bad programming 
> > habits, I guess in the name of liberty... or one day they will 
> eventually 
> > arbitrate what is good and bad in those areas too. 
> > 
> > Could it be that Go lang devs created an inflexibility, a storm in a 
> > tea-cup, for no real good reason. Such things have happened in software 
> > before. 
>
> I doubt there is any significant disagreement among the core Go 
> developers about the gofmt choices for brace placements.  The reasons 
> are 1) it doesn't matter, gofmt just has to make a choice; 2) the 
> choice works well with lexical semicolon insertion. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[Ecstatic Coder]

Btw please don't take it personally. What I'm saying is that indeed some
people (including me as you see) WILL NEVER agree to be forced to change
their coding style because Google engineers have decided so, but that
doesn't mean we should stay away from go just because of our mental
incapacity to agree on that.

On Thu, Jul 27, 2017 at 9:32 AM,  wrote:

> I don't know if you have read this post above :
>
> "BTW, I've just released Genesis, an open source generic preprocessor
> which automatically converts Allman style code into K and allows
> genericity by parametric instantiation.
>
> https://github.com/senselogic/GENESIS
>
> Better late than never... ;)"
>
> Obviously, I don't like AT ALL the K style, to which I prefer the Allman
> style, for not only personal but also OBJECTIVE reasons.
>
> And yet I've learned Go and enjoy a lot to use this language, despite this
> implies using an external tool to add genericity and fix the code
> indentation.
>
> Btw here are the result of a small internet poll on indentation styles :
>
> - Allman : 7450 votes
> - K style : 5514 votes
> - Whitesmith : 455
> - GNU : 422
> - Horstman : 131
> - Pico : 93
> - Banner : 243
>
> (http://www.terminally-incoherent.com/blog/2009/04/
> 10/the-only-correct-indent-style)
>
> Even if these 14000 votes are obviously not enough to reflect the whole
> development community, at least you can see here that many developers
> prefer the Allman style to the K style.
>
> So sorry, but I completely disagree with your advice to stay away from Go
> if you don't like its forced indentation style policy.
>
> It's not only too radical, but also not needed, as there are already tools
> to fix that issue.
>
>
> On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>>
>> I propose a new rule for our Code of Conduct: Before posting to the "No
>> Allman-Style, No go!" thread, you shall read and understand all previous
>> posts in the aforementioned thread.
>>
>> Justo to be clear: Go indentation style is a time saver. It was carefuly
>> crafted to piss some people off.  As you can see, it works wonders. If
>> someone can't handle a simple change in indentation style, then she has no
>> business trying to learn Go, so she quits, thus saving time.
>>
> --
> 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/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

I don't know if you have read this post above :

"BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K and allows genericity by 
parametric instantiation.

https://github.com/senselogic/GENESIS

Better late than never... ;)"

Obviously, I don't like AT ALL the K style, to which I prefer the Allman 
style, for not only personal but also OBJECTIVE reasons.

And yet I've learned Go and enjoy a lot to use this language, despite this 
implies using an external tool to add genericity and fix the code 
indentation.

Btw here are the result of a small internet poll on indentation styles :

- Allman : 7450 votes
- K style : 5514 votes
- Whitesmith : 455
- GNU : 422
- Horstman : 131
- Pico : 93
- Banner : 243

(http://www.terminally-incoherent.com/blog/2009/04/10/the-only-correct-indent-style)

Even if these 14000 votes are obviously not enough to reflect the whole 
development community, at least you can see here that many developers 
prefer the Allman style to the K style.

So sorry, but I completely disagree with your advice to stay away from Go 
if you don't like its forced indentation style policy.

It's not only too radical, but also not needed, as there are already tools 
to fix that issue.

On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>
> I propose a new rule for our Code of Conduct: Before posting to the "No 
> Allman-Style, No go!" thread, you shall read and understand all previous 
> posts in the aforementioned thread.
>
> Justo to be clear: Go indentation style is a time saver. It was carefuly 
> crafted to piss some people off.  As you can see, it works wonders. If 
> someone can't handle a simple change in indentation style, then she has no 
> business trying to learn Go, so she quits, thus saving time.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

Nice idea, but unfortunately that was not easy to do with my favorite code 
editor (Geany).

That's why I've implemented a preprocessor (Genesis) which converts my 
Allmann-style files to Golang-style.

On Saturday, July 22, 2017 at 11:59:04 AM UTC+1, ohir wrote:
>
>
> Every development team has right to reformat source to their tastes on 
> the editor openfile then reformat to compiler taste on savefile. 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

That's the problem. Indentation style should remain personal, as it's a 
matter of taste.

Every development team should have the right to freely choose which coding 
standard they will enforce.

On Friday, July 21, 2017 at 3:22:50 PM UTC+1, Hrobjartur Thorsteinsson 
wrote:
>
> Best just to call this golang style, or the wrong K style. They have 
> converted their own style into syntax.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K and allows genericity by 
parametric instantiation.

https://github.com/senselogic/GENESIS

Better late than never... ;)

On Saturday, September 21, 2013 at 3:58:03 AM UTC+2, Michael Daconta wrote:
>
> Hi Go fans,
>
> I frankly was shocked to learn that a program like:
>
> package main;
>
> import "fmt";
>
> func main() 
> {
> fmt.Printf("hello, world!\n");
> }
>
> ... is currently illegal in go with the error:
>
> # command-line-arguments
> .\hello.go:6: syntax error: unexpected semicolon or newline before {
>
> From reading the newsgroups, I see that this is illegal due to the 
> automatic insertion of semi-colons; however, what if I added my own 
> semi-colons into the code as in the above.  From a language perspective the 
> above should be legal Go code.  To me, it seems like a hack for convenience 
> (making semi-colons optional) has forced a K style on everyone.
> For me, this is a show-stopper.  Frankly, I am surprised that Google would 
> enforce a coding style (K) while saying that "go fmt" frees you from 
> worrying about divergent coding styles.  Sorry, google - you cannot have it 
> both ways.  Unless the Allman-style code above is illegal in the language 
> (which makes no sense from a language semantics point of view) - get the 
> compiler to accept it. Period.
>
> Yes, I know I can write my own translator - but why?  Heck, I can just 
> stick with Java...
>
> C'mon Google, when trying to pitch a new language, you can (and should) do 
> better than this...
>
> - Mike
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.