no min/max for integer + no ternary if/then/else operator = ??

[Benjamin G.]

Still trying to dive into Go tonight, another question for which i found no recent answer on the mailing list: 

I've tried to find a way to compute the maximum of two integer in one line of code (which, to my knowledge, every single programming language has been able to do since the 70's), and was pretty amazed to find nothing.

Could someone please tell me i'm just blind ?

[Dave Cheney]

> I've tried to find a way to compute the maximum of two integer in one line
> of code (which, to my knowledge, every single programming language has been
> able to do since the 70's), and was pretty amazed to find nothing.

Because the math package is not polymorphic, you have to write them
yourself. The inliner can cope with these simple functions

http://code.google.com/p/go/source/browse/ssh/client.go?repo=crypto#452

> Could someone please tell me i'm just blind ?

Sadly there is no ternary form in Go.

http://golang.org/doc/go_faq.html#Does_Go_have_a_ternary_form

Cheers

Dave

[Kyle Lemons]

Actually, I don't think the inliner will inline

func max(a, b int) int {

   if a < b {

      return b

   }

   return a

}

since it isn't a one-liner.  I could be wrong though...

[Benjamin G.]

......

I'm sorry, but i really can't believe it. I've read a thread were someone was saying "i don't want to add those function in math because it would release the pressure for generics".  Since that was a few years ago, i really hoped someone would have taken care of that situation since then.

So, what you mean is that every single project will have to redefine its own math library dealing with integer just because of pure ideology (on one side at least) ? 

I mean, this is such a trivial feature that the only fact that the solution to it is a subject of internal discussion gives me the creep. I don't mind coding my own min/max/abs functions, but i mind having to do it a LOT.

I was planning on starting a small project with go in the coming weeks, because i loved what I saw so far, but that kind of things is really like a huge stop sign in the middle of the road...

Is anyone planning on creating a somewhat decent math package that anybody else would use ?

[andrey mirtchovski]

> I'm sorry, but i really can't believe it.

you're in for a surprise, then :)

[Rémy Oudompheng]

Le 30 mars 2012 23:40, Benjamin G. <benjamin....@gmail.com> a écrit :
> Is anyone planning on creating a somewhat decent math package that anybody
> else would use ?

What do you want to see in it? I'm not sure how it solves the problem.

Rémy.

[Jan Mercl]

On Friday, March 30, 2012 11:40:46 PM UTC+2, Benjamin G. wrote:

......

I'm sorry, but i really can't believe it. I've read a thread were someone was saying "i don't want to add those function in math because it would release the pressure for generics".  Since that was a few years ago, i really hoped someone would have taken care of that situation since then.

So, what you mean is that every single project will have to redefine its own math library dealing with integer just because of pure ideology (on one side at least) ? 

I mean, this is such a trivial feature that the only fact that the solution to it is a subject of internal discussion gives me the creep. I don't mind coding my own min/max/abs functions, but i mind having to do it a LOT.

Why a LOT? Once is not enough? Why?

 

I was planning on starting a small project with go in the coming weeks, because i loved what I saw so far, but that kind of things is really like a huge stop sign in the middle of the road...

Is anyone planning on creating a somewhat decent math package that anybody else would use ?

And as we are using in an order of magnitude more words to discuss writing of a function (which probably fits a punch card capacity): Perhaps slightly OT, but you might enjoy reading: http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html

[DisposaBoy]

On Friday, March 30, 2012 10:40:46 PM UTC+1, Benjamin G. wrote:

......

I'm sorry, but i really can't believe it. I've read a thread were someone was saying "i don't want to add those function in math because it would release the pressure for generics".  Since that was a few years ago, i really hoped someone would have taken care of that situation since then.

So, what you mean is that every single project will have to redefine its own math library dealing with integer just because of pure ideology (on one side at least) ? 

Not true

 

I mean, this is such a trivial feature that the only fact that the solution to it is a subject of internal discussion gives me the creep.

If it is indeed so trivial, I personally await your proposal for a solution to the generics problem that actually works

[Benjamin G.]

I think people here misunderstood me. I'm not entering the pro/cons of generics in GO debate (i've been writing Go for only 2 hours now, that would be a bit premature i guess), i'm just saying that you can't release a v1.0 programming language in 2012 that doesn't gives you those extremely common functions right of the shelves for built-in types (no matter how, using generics or hard-coding the functions , i absolutely don't care at all and have no opinion on that).

Especially one that advertises a "modern dynamic language" feeling.

[Kyle Lemons]

On Fri, Mar 30, 2012 at 3:12 PM, Benjamin G. <benjamin....@gmail.com> wrote:

I think people here misunderstood me. I'm not entering the pro/cons of generics in GO debate (i've been writing Go for only 2 hours now, that would be a bit premature i guess), i'm just saying that you can't release a v1.0 programming language in 2012

I think you'll find that we just did.  Based on the uptick in mailing list and IRC traffic, I think it's been a success.

that doesn't gives you those extremely common functions right of the shelves for built-in types (no matter how, using generics or hard-coding the functions , i absolutely don't care at all and have no opinion on that).

http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature_X

Especially one that advertises a "modern dynamic language" feeling.

I don't see how not providing min, max, and abs as language builtins solves this problem.  If we had those, then people would want insert() and delete() and then people would want trunc() and ceil() and float.  You may wish to argue that Min and Max should be in the math package, but the truth of the matter is that you can always write one yourself once and be done with it, and that there are many situations where min(a,b) is not really what you want; you may want min(...int) or any number of other things that only you and your application can implement correctly and efficiently.

[si guy]

A few months ago I would have agreed, but after rolling my own int math library my own code was _actually_ harder to read than with inline math, live and learn I guess.

If there is a math/int lib I know I won't use it.

-1

[Benjamin G.]

On Saturday, March 31, 2012 12:18:34 AM UTC+2, Kyle Lemons wrote:

I think people here misunderstood me. I'm not entering the pro/cons of generics in GO debate (i've been writing Go for only 2 hours now, that would be a bit premature i guess), i'm just saying that you can't release a v1.0 programming language in 2012

I think you'll find that we just did.  Based on the uptick in mailing list and IRC traffic, I think it's been a success.

I'm part of those people that are new to Go, which have been seduced by all the presentations, videos, and articles written recently. I do have huge hopes for that language.  But saying that because people come and see, then it's a success, is a bit optimistic i think.

 

that doesn't gives you those extremely common functions right of the shelves for built-in types (no matter how, using generics or hard-coding the functions , i absolutely don't care at all and have no opinion on that).

http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature_X

Actually, i didn't think one would still call min/max a language "feature" as of today.

 

Especially one that advertises a "modern dynamic language" feeling.

I don't see how not providing min, max, and abs as language builtins solves this problem.  If we had those, then people would want insert() and delete() and then people would want trunc() and ceil() and float.  You may wish to argue that Min and Max should be in the math package, but the truth of the matter is that you can always write one yourself once and be done with it, and that there are many situations where min(a,b) is not really what you want; you may want min(...int) or any number of other things that only you and your application can implement correctly and efficiently.

It's just a matter of what the average developer takes for granted when he starts developing with a new language. Modern Dynamic = fast and efficient syntax & framework that lets you reduce the amount of non-original, dumb, tedious code that fills 90% of your screen.

Actually, the go syntax is absolutely wonderful in that matter, and seemed to completely be focused on those objectives. That's why I couldn't believe something as basic as the math lib had such big gaps. 

Btw, why coding "min/max/abs" for float in math, then ? 

[Benjamin G.]

So does that mean you're not using the current math/float lib for min/max/abs ?

[andrey mirtchovski]

> Actually, i didn't think one would still call min/max a language "feature"
> as of today.

what is min(a,b) equal to when a=interface{} and b=interface{}? for
that matter, what is it equal to when they are structs?

[Benjamin G.]

Easy, 

pick any : 

http://www.w3schools.com/js/js_obj_math.asp

http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Math.html

http://docs.python.org/library/functions.html

http://msdn.microsoft.com/en-us/library/xaz41263(v=vs.71).aspx

Objective-C puts the macros in NSObjcRuntime.h

[Benjamin G.]

Why do you want to know that ? Once again, i'm not arguing about generics...

I'm not asking for much : just give me the name of one single language that doesn't provide min/max/abs for basic numerical types... I've sent a list of links in a post right above where you can see for yourself what "regular" developers take for granted.

[Rob 'Commander' Pike]

On Sat, Mar 31, 2012 at 10:15 AM, Benjamin G.
<benjamin....@gmail.com> wrote:
> I'm not asking for much : just give me the name of one single language that
> doesn't provide min/max/abs for basic numerical types...

C

-rob

[Benjamin G.]

I completely understand your point of view, but just in case you don't realize what i'm talking about : 

You are probably already confident in the Go language. You've probably done a few projects with it, and know that it can solve your issues elegantly. So, when someone asks for such a trivial features, you think that he completely misses the point. Which may be true.

I'm not like you. I've seen the slides, the promisses, the marketing, but i know i can't trust that, so I have to see for myself what this language is for real. Whether it will really address my issues, or if it's just either marketing stunt, or simply not focused for my needs.

So what do I do ? Well, i code basic things, and see if that language solves the very basic solutions elegantly. Because, hey, if you can't do a min/max elegantly, then how can you expect it to do anything hard. And whenever i see weird things, things that are less elegant , or missing, my confidence in that language drops a bit. Until it reaches the point when i'll just leave it behind and check another one.

That's just basic, raw, common sense. It may be wrong, but i'm very confident that's how the vast majority of the average developers think (you know, the one people  try to make adopt their brand new language, so that it doesn't remain a niche).

[Benjamin G.]

Don't want to show disrespect, but anything more "modern" or "dynamic" ;) ?

Plus, at least C gives you ternary if/then/else operator...

Once again, i know that thing really IS minor, and i've made a more detailled answer above as to why this preoccupies me. Make no mistake, i've just spent the last weeks diving into some horribly bloated and highly advertised java web framework that solves pretty much everything useless and nothing useful, and the previous year dealing with overhyped highly advertised dynamic-language frameworks  that tells people to basically write types in code comments and replace compilation with manual unit-testing. 

So you can't imagine how much i would LOVE to see go become the new mainstream language, at least for the server side. It's just that I know that those are the kind of minor things that me rebuke many (average) developers. 

On Saturday, March 31, 2012 1:21:20 AM UTC+2, r wrote:

On Sat, Mar 31, 2012 at 10:15 AM, Benjamin G.

[Devon H. O'Dell]

Op 30 maart 2012 19:42 heeft Benjamin G.
<benjamin....@gmail.com> het volgende geschreven:

> Don't want to show disrespect, but anything more "modern" or "dynamic" ;) ?
> Plus, at least C gives you ternary if/then/else operator...

You're not the first to complain about the lack of a ternary operator
nor the first to wonder about min/max on non-float types. I'm sure
that I have wondered / complained about it (though perhaps not so
publicly / persistently) at some point in the past.

Have you spent much time with Go? If not, it's worth doing. Many who
have complained have found that they are OK with the lack of these
things. Still others have found they are not OK and gone on to using
other languages.

> Once again, i know that thing really IS minor, and i've made a more
> detailled answer above as to why this preoccupies me. Make no mistake, i've
> just spent the last weeks diving into some horribly bloated and highly
> advertised java web framework that solves pretty much everything useless and
> nothing useful, and the previous year dealing with overhyped highly
> advertised dynamic-language frameworks  that tells people to basically write
> types in code comments and replace compilation with manual unit-testing.
>
> So you can't imagine how much i would LOVE to see go become the new
> mainstream language, at least for the server side. It's just that I know
> that those are the kind of minor things that me rebuke many (average)
> developers.

It really isn't a big deal to write your own IntMin and IntMax
functions when and where you need them. If the lack of something that
saves you 4 lines of code max is a deal breaker for using a language,
perhaps the "easier" languages are best for you. Personally, I would
love it if Go did not become "the new mainstream language." The Ruby
On Rails and node.js hype camps are really silly.

[Sanjay Menakuru]

Sorry, I'm curious, why the one line limit?

You say every language can do it in one line. Can all those languages start an (efficient) HTTP server in ~10 lines?

You win some, you lose some. Personally, I like Go's tradeoffs.

I hope you can bring yourself to write the if statement that solves this "problem" and give the language a chance. It really is pretty awesome.

Sanjay

[Benjamin G.]

On Saturday, March 31, 2012 1:52:38 AM UTC+2, Devon H. O'Dell wrote:

Op 30 maart 2012 19:42 heeft Benjamin G.

> Don't want to show disrespect, but anything more "modern" or "dynamic" ;) ?
> Plus, at least C gives you ternary if/then/else operator...

You're not the first to complain about the lack of a ternary operator
nor the first to wonder about min/max on non-float types. I'm sure
that I have wondered / complained about it (though perhaps not so
publicly / persistently) at some point in the past.

Yes, but that's only because of the high hopes i have for that language.

 

Have you spent much time with Go? If not, it's worth doing. Many who
have complained have found that they are OK with the lack of these
things. Still others have found they are not OK and gone on to using
other languages.

> Once again, i know that thing really IS minor, and i've made a more
> detailled answer above as to why this preoccupies me. Make no mistake, i've
> just spent the last weeks diving into some horribly bloated and highly
> advertised java web framework that solves pretty much everything useless and
> nothing useful, and the previous year dealing with overhyped highly
> advertised dynamic-language frameworks  that tells people to basically write
> types in code comments and replace compilation with manual unit-testing.
>
> So you can't imagine how much i would LOVE to see go become the new
> mainstream language, at least for the server side. It's just that I know
> that those are the kind of minor things that me rebuke many (average)
> developers.

It really isn't a big deal to write your own IntMin and IntMax
functions when and where you need them. If the lack of something that
saves you 4 lines of code max is a deal breaker for using a language,
perhaps the "easier" languages are best for you. Personally, I would
love it if Go did not become "the new mainstream language." The Ruby
On Rails and node.js hype camps are really silly.

I've been saying so myself: this is, in itself, minor. But since it's just four lines, since some people have been complaining about it in the past, and since the solution for covering 90% of the needs is just to add those 4 lines that every go developer in the world will type one day, then why not shipping it in the lib itself ? I don't understand the logic.

Is it because the go team is not really happy with the idea of doing copy/paste / replace (float , int) in math.lib ?

In any case, this absence does raise questions about the language itself. And that's the kind of question that are very damaging for language adoption.

 

> On Saturday, March 31, 2012 1:21:20 AM UTC+2, r wrote:
>>
>> On Sat, Mar 31, 2012 at 10:15 AM, Benjamin G.
>> > I'm not asking for much : just give me the name of one single language
>> > that
>> > doesn't provide min/max/abs for basic numerical types...
>>
>> C
>>
>> -rob

On Saturday, March 31, 2012 1:52:38 AM UTC+2, Devon H. O'Dell wrote:

Op 30 maart 2012 19:42 heeft Benjamin G.

[Jim Whitehead II]

There are 12-15 numeric types (give or take). You'd like to see
Max/Min/Abs for them.
There are 61 functions in the math package, which all work on float64s
and seem to work quite well.

Having all of these 'trivial but required' functions would almost
double the size of the library, and you would lose the consistency you
already have with them working on floats and being well defined.

If you say you want just Int, then why not the other types? You can
already cast the integer types to floating types and use the library
that is already quite well defined.

- Jim

[Rémy Oudompheng]

Le 31 mars 2012 01:31, Benjamin G. <benjamin....@gmail.com> a écrit :
> So what do I do ? Well, i code basic things, and see if that language solves
> the very basic solutions elegantly. Because, hey, if you can't do a min/max
> elegantly, then how can you expect it to do anything hard. And whenever i
> see weird things, things that are less elegant , or missing, my confidence
> in that language drops a bit. Until it reaches the point when i'll just
> leave it behind and check another one.

There's no reason the lack of min/max prevents you from writing
something hard. I've written non-basic Go programs for a few months
now, and I may have needed min/max once or twice, but my screen was
certainly never covered at 90% by tedious code. Whenever I needed
min/max more than twice (which actually never happened), I would have
written a little helper function somewhere.

I lack min, max as much as I would miss map, fold, or list
comprehensions. It may be annoying for a second, but that's all. What
do you need min/max for? Actually, if I had min/max in a language but
was proposed to get list/array comprehensions instead, I would not
hesitate to trade.

Why do you think it's horrible to have all Go developers in the world define
func max(a, b int) int { if a > b { return a }; return b }

It's a single line, not 4. But you don't put code in a language spec,
you put code in libraries. It takes as many lines of code to import a
library with a trivial function than to write it directly. If you
write the function yourself, you win the advantage of not falling in
the traps of special cases of the function you imported because it
didn't you what you think it did.

And, anyway, I only saw that function in people's code once in dozens.

Rémy.

[Sameer Ajmani]

Building on this point: as you use Go, you will encounter many occasions where a common 3-5 line helper function appears to be "missing": not just min/max, but also helpers to extract the keys or values from maps into slices, and helpers to gather results from a channel into slices, and helpers to map functions over elements of a map or slice in parallel, and.... you get the idea. Instead of providing oodles of libraries to handle all these cases, Go gives you a small, easy to remember set of powerful primitives and core libraries. This makes it easier to hold the language and libraries in your head, which means it's easier to write code without flipping back and forth to reference pages. As a result, you spend longer stretches of time in the programming flow, and you end up getting more done.  This is something that you won't fully appreciate until you try using the language to write a real program.

[Benjamin G.]

Thanks, that's exactly the kind of answer I was looking for.

I'm used to having the full library documentation available inline in my IDE, along with autocompletion, and i don't do very low-level or system programming. So those concerns of having too big core libraries (with big being a few hundreds of kilobytes), or trying to keep all the lib method signature in my head in order to keep the coding flow aren't clearly obvious to me.

I'll try to keep on trying that language and not let those missing helper-like functions bother me too much.

Getting late

Ben

On Saturday, March 31, 2012 2:41:46 AM UTC+2, Sameer Ajmani wrote:

Building on this point: as you use Go, you will encounter many occasions where a common 3-5 line helper function appears to be "missing": not just min/max, but also helpers to extract the keys or values from maps into slices, and helpers to gather results from a channel into slices, and helpers to map functions over elements of a map or slice in parallel, and.... you get the idea. Instead of providing oodles of libraries to handle all these cases, Go gives you a small, easy to remember set of powerful primitives and core libraries. This makes it easier to hold the language and libraries in your head, which means it's easier to write code without flipping back and forth to reference pages. As a result, you spend longer stretches of time in the programming flow, and you end up getting more done.  This is something that you won't fully appreciate until you try using the language to write a real program.

[Liigo Zhuang]

IMO, Go1 release a little early. We need time to fix & improve the language and libraries. If it has another year's time before go1, that would be very OK. But it just occured. Go1's compatibility will be a burden for go team developers to fix or change something.

2012/3/31 Benjamin G. <benjamin....@gmail.com>

--
by Liigo, http://blog.csdn.net/liigo/

Google+  https://plus.google.com/105597640837742873343/

[Ugorji Nwoke]

The Go Authors spent 2 years developing Go before releasing it to the rest of the world open-source in Nov 2009. With a pretty large and involved community, they have made changes and defended decisions when necessary. New folks are really coming in after over 4 years of hard-core development and usage of the language. What I'm saying is that there is usually a pretty good answer for things that seem lacking.

- Ternary operators. I love it. Many more-hardened software folks hate it, because it has been abused a lot to create pretty unreadable code. The Go Authors decided early on that they would not support it. Case closed. I still miss it sometimes, but not so much (even though I used it all across my codebase while coding in java for over 10 years).

- min/max: There's a large number of primitive integer types (signed and unsigned int8, 16, 32, 64). And Go does not do function name overloading. In practice, this makes life very easy (you can reference a function just by its name, for example). And Go "currently" doesn't do generic functions. And Go elides magic (so no automatic boxing/unboxing of types to make them fatter or smaller behind the scenes). IMO, it's impractical to define such a "simple" function and allow it fill up the package namespace, especially where the function is not universally used or hard. I've been coding Go hard now for over a year, and I haven't missed that function. YMMV. But if I needed it, it would be a short function for the specific type I need it for in my toolbox.

There will be a number of things which are different with Go. Take it from those of us that have used it for a while now. It's a crazy sexy language, once you get past yourself and give it a chance. Your code starts to read like prose, and you start to "dislike" other languages when you go back. 

Go1 is really a v2.0 language. It's been very very stable for way over a year and is already being used in real production deployments, both inside and outside Google. Look at the breadth of the modern standard library. I haven't had to really look outside of the core library for anything, which is way different from my experience with java (where I constantly needed an external framework or external jar).

The Go Authors earlier always told us that you have to think in Go and leave your preconceptions outside when you start. Take their advice - your experience will be very very rewarding. 

[Steven Blenkinsop]

Another reason not to add math functions for every numeric type: all those functions will be used by someone, so if/when Go gets generics, those functions will be an unsightly legacy that can't be gotten rid of without breaking a ton of code. Whereas, if people just write the darn one-liner on the rare occasion they need it, the standard library doesn't have to carry it around. So, the library interface is better because it's worse.

[John Asmuth]

On Friday, March 30, 2012 8:59:46 PM UTC-4, Benjamin G. wrote:

I'll try to keep on trying that language and not let those missing helper-like functions bother me too much.

Glad to hear it. The 10 second cost of writing "func MinInt(x, y int) (r int) { if x < y { return x } return y }" are a small price to pay for the other benefits we see with go. Among which number the intentionally feature-poor approach of the designers that serves to keep the language lean and mean.

[kar]

2 years more than enough to have stable syntax, that's what most of us care about. As with other languages, 3rd party libraries will grow enough to cover most topics. 

". A timeline provided in the presentation has JDK 9 arriving in 2015, JDK 10 in 2017, JDK 11 in 2019, and JDK 12 in 2021." <- 2 years is all it takes.

[Graham Anderson]

On Friday 30 Mar 2012 17:59:46 Benjamin G. wrote:
> Thanks, that's exactly the kind of answer I was looking for.
> I'm used to having the full library documentation available inline in my
> IDE, along with autocompletion, and i don't do very low-level or system
> programming. So those concerns of having too big core libraries (with big
> being a few hundreds of kilobytes), or trying to keep all the lib method
> signature in my head in order to keep the coding flow aren't clearly
> obvious to me.

For what it's worth... Some of the plugins (vim for sure) in the misc/vim dir
of the release tarball provide useful documentation integration, and there's
the github.com/nsf/gocode autocompletion helper.

--
That which can be asserted without evidence, can be dismissed without
evidence.

[Rasmus Schultz]

It seems silly not to have such basic functions available.

And no, it's not the 10 second cost of writing your own min/max functions, but the 20 minutes every new developer will waste trying to understand why they have to write a function that was built into whatever language(s) they were using before.

Go aims to be pragmatic. Sorry, but the absence of basic math functions - not pragmatic at all.

[Kyle Lemons]

On Wed, Dec 18, 2013 at 4:39 PM, Rasmus Schultz <ras...@mindplay.dk> wrote:

It seems silly not to have such basic functions available.

And no, it's not the 10 second cost of writing your own min/max functions, but the 20 minutes every new developer will waste trying to understand why they have to write a function that was built into whatever language(s) they were using before.

The biggest cost, the way I see it, is the thousands of man-hours that have been devoted to reading/answering this question on the mailing list :).

It's not going to be added as a builtin.  That would set a bad precedent.  It's not going to be added as a library function, becuause we would have to have one for {u}int{,8,16,32,64} and float{32,64} or one using interface{}, and I'm sure you can see why neither of those are good options.

 

Go aims to be pragmatic. Sorry, but the absence of basic math functions - not pragmatic at all.

On Friday, March 30, 2012 11:43:27 PM UTC-4, John Asmuth wrote:

On Friday, March 30, 2012 8:59:46 PM UTC-4, Benjamin G. wrote:

I'll try to keep on trying that language and not let those missing helper-like functions bother me too much.

Glad to hear it. The 10 second cost of writing "func MinInt(x, y int) (r int) { if x < y { return x } return y }" are a small price to pay for the other benefits we see with go. Among which number the intentionally feature-poor approach of the designers that serves to keep the language lean and mean.

--
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/groups/opt_out.

[Michael Jones]

On Wed, Dec 18, 2013 at 5:02 PM, Kyle Lemons <kev...@google.com> wrote:

It's not going to be added as a library function, becuause we would have to have one for {u}int{,8,16,32,64} and float{32,64}

​...as it happens I have just this for all my Go programs.​

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

(Note: this email has been shared with you under the terms of Regulation 23)

[Dave Cheney]

Here ya' go. Almost 100% autogenerated as well.

I'm not sure if it is a good idea, but in case you cannot bear to
write these functions yourself.

https://godoc.org/github.com/pkg/math

[Scott Pakin]

On Wednesday, December 18, 2013 6:51:47 PM UTC-7, Dave Cheney wrote:

Here ya' go. Almost 100% autogenerated as well.

I'm not sure if it is a good idea, but in case you cannot bear to
write these functions yourself.

https://godoc.org/github.com/pkg/math 

There's also https://github.com/cznic/mathutil, incidentally (found on the Go wiki Projects page; I haven't actually used it myself).

— Scott

[Kevin Gillette]

It could be said that the 20 minutes each developer spends figuring this out is a necessary lesson that they shouldn't go looking for trivial functions. The only reason math.Max exists is because floats have non-trivial semantics, such as Inf and NaN, which integers do not.

It's also a good way for newcomers to become better programmers: at least one person has asked on this mailing list why they're forced to convert int -> float64, call math.Max with that, then convert float64 -> int. To many of us, that's clearly a bad idea for a number of reasons (precision loss if int happens to be 64-bits wide, and wasteful, wasteful, utterly wasteful inefficiency just to save 3 lines of code).

Certainly the FAQ, and other introductory documents could address this point, along the lines of "when you're spending more time looking for reusable library code than it would take you to correctly write that same code, you're expected to write it yourself."

[Rasmus Schultz]

> It's not going to be added as a library function, becuause we would have to have one for {u}int{,8,16,32,64} and float{32,64} or one using interface{}, and I'm sure you can see why neither of those are good options

A justifiable use-case for overloading?

Since the only reason you actually need different functions for different size ints for something like Max() is purely technical and/or performance-related, and the implementation details of such functions is most likely of no interest and no practical relevance to anyone...

This sort of thing is a distraction, pure and simple, no matter how you turn it...

[Kevin Gillette]

On Thursday, December 19, 2013 9:06:54 PM UTC-7, Rasmus Schultz wrote:

> It's not going to be added as a library function, becuause we would have to have one for {u}int{,8,16,32,64} and float{32,64} or one using interface{}, and I'm sure you can see why neither of those are good options

A justifiable use-case for overloading?

Maybe. But think of all the unjustifiable cases that people would be naturally predisposed toward:

func Add(int8, int8) int64

func Add(int8, int16) int64

func Add(int16, int8) int64

/* ... */

func Add(int64, int64) int64

func Add(int8, string) string

/* ... ad infinitum ... */

people do this kind of thing when you give them the opportunity, just because they can, because they think that "native" functions (that operate directly on their desired combination of types) are somehow much more efficient or more accurate than explicit conversions, and also because they think they're clever and are offering the community/world a real benefit of some kind. Overloading often just produces very, very poor, bloated APIs, and many of it's use cases can be better served by proper generics, or explicit argument handling.

For int based min/max, the only "useful" reusable functions would be the following set of four:

MinInt(a, b int64) int64

MaxInt(a, b int64) int64

MinUint(a, b uint64) uint64

MaxUint(a, b uint64) uint64

If you want to do it with int8's?

var a, b int8 = 1, 7

min := int8(MinInt(int64(a), int64(b)))

Since the inputs are int8 values, the output is guaranteed, for any min or max function, to also be representable as an int8.

[Rasmus Schultz]

Repeating the type-name in every function-call? No, I'm not sure that's a good idea either.

And no, it's not that I can't "bear" to write it myself :-)

What irks me, is that calculating the maximum of two numbers (or any other basic math operation) is most likely not an operation that has any relevance to whatever your program or library is doing. (unless it happens to be a math program or math library.)

So every program and library may end up with it's own implementations of min or max (or other trivial functions) which I see as distractions from whatever it is the program or library is doing that actually makes it important or useful.

Also, the first time you need something as trivial as a max function, you're probably not going to actually add it as a function - I didn't want the extra function, so I calculated it inline. When should I refactor? After two operations? Three? What if I end up needing it two different modules, do I factor it out into a library? Not choices you want to spend time on. Distractions.

So to keep things simple, I keep the max calculation inline. Verbose. Distracting to read. Not semantic. (words like "if" and "else" do not communicate what you're doing and must be "parsed" by the reader on every encounter.)

Neither are good options.

The problem, in my opinion, is that math.Max() exists - you want to do well, you've been taught not to "roll your own" when something is already available, so it's logical to think that's what you should be using - but you can't...

For a language that aims to be simple and pragmatic, lacking basic maths seems like a pretty big distraction, even if there are underlying reasons (or in my opinion causes) that explain why.

Anyhow, I've learned my lesson, and this is not a showstopper for me, so I'm moving on - bigger fish to fry :-)

[Rasmus Schultz]

> Overloading often just produces very, very poor, bloated APIs, and many of it's use cases can be better served by proper generics

Agreed - if this could be solved with generics (which I've heard the Go team is open to) that would be even better :-)

[Kevin Gillette]

On Thursday, December 19, 2013 9:35:56 PM UTC-7, Rasmus Schultz wrote:

Also, the first time you need something as trivial as a max function, you're probably not going to actually add it as a function - I didn't want the extra function, so I calculated it inline. When should I refactor? After two operations? Three? What if I end up needing it two different modules, do I factor it out into a library? Not choices you want to spend time on. Distractions.

As of now, min/max style functions can be inlined, so there's literally no benefit to not defining the function. That said, how many min/max variants need to be defined to support all the necessary int types being used by a package? My expectation is that the average answer rounds to 1.

 

The problem, in my opinion, is that math.Max() exists - you want to do well, you've been taught not to "roll your own" when something is already available, so it's logical to think that's what you should be using - but you can't...

That's part of the problem. NIH is not an incontrovertible universal truth, but rather just a preference held on a language-by-language basis. Some language communities would rather you spend 5 minutes looking for an implementation of a function you could have written in 30 seconds. Go takes more of a "time is time" approach -- do whichever takes less time. To fully accept the zen of Go (or the zen of any language), one must be willing and able to give some of their assumptions.

 

Anyhow, I've learned my lesson, and this is not a showstopper for me, so I'm moving on - bigger fish to fry :-)

Exactly. IMO, it's a question of whether that lesson is easy enough to learn, rather than whether the language/stdlib should change to make the lesson unnecessary.

On Thursday, December 19, 2013 9:40:38 PM UTC-7, Rasmus Schultz wrote:

> Overloading often just produces very, very poor, bloated APIs, and many of it's use cases can be better served by proper generics

Agreed - if this could be solved with generics (which I've heard the Go team is open to) that would be even better :-)

Yes, as I understand it, the core team is receptive to a proper, solid generics proposal, but much of the onus is on the proposer to make sure they avoid the limitations which other proposals have suffered from. In this community, orthogonality and consistency are more important than the feature-set (otherwise we'd be C++ or D, which are known to favor what people popularly want, rather than what is reasonable and good for them); any proposal can adequately "wow" the core team without making large compromises will likely get attention. The fact that this hasn't happened yet is an indication of how difficult that is to do within the context of Go 1. If proposals avoided Go 1 as a target and instead focused on the hypothetical Go 2, they'd have much more freedom to avoid those fatal compromises, but ironically, with Go 2 still so far away, any Go 2 proposal may be forgotten or ignored well before it has a chance to be implemented.

[Kevin Gillette]

On Friday, December 20, 2013 12:04:39 AM UTC-7, Kevin Gillette wrote:

To fully accept the zen of Go (or the zen of any language), one must be willing and able to give some of their assumptions.

... must be willing to give up some of their assumptions.

[Dave Cheney]

Those are all valid points, but the language as it stands today does
not have function overloading nor templated functions (which would
require type inheritance).

Given the philosophy behind the language, I do not see either being
added.So you can either write min and max when you need them, or use
this package.

To be honest, I'm probably going to keep doing the former. This
project was more an experiment in how one could generate all the
permutations automatically although these functions are just as
performant as ones you could write yourself, well, the 2 arg forms
are, and will inline just as well as any version you write.

Cheers

Dave

[deck...@gmail.com]

Here is some perspective from a relative new-comer to Go:

I was also kind of shocked about the lack of some of these helper methods in Go.  My initial reaction was: "Why the hell do the most basic, primitive functions not exist in Go?"

Fast forward, 20 minutes later, and I was over it. I'm coming from 7+ years of C# which I've always said is a great language and perhaps a better version of Java.  C# has generics and it works pretty well

but I've seen the generics syntax abused to death.  For simple types, it's not bad but when people go overboard trying to make everything generic and adding generic constraints and further wrapping

their generic solutions in design patterns and then unveiling their giant mess to the world I think a little kitten dies each time.

I think people forget that with Go, simplicity is held in high regard.  Yes, you give up certain language features but you gain so much in readability, maintainability and expressiveness.  There is no perfect language and I'm sure Go will continue to improve and perhaps one day have generics.  But until the maintainers find a solution to generics that is simple and robust it's just not going to happen.

And you know what?  I'm okay with that because if I needed it that bad...I'd just move back to C#, or Java, or C++ or whatever language has the feature you so desperately desire.

I'm wanting to root for the Go team because I see a lot of complaints about what Go lacks.  How about instead we sit down with the language for more than 1 hour so we can learn about the many, many other areas of what Go has gotten right.

Thanks,

-Ralph

[Rasmus Schultz]

> I'm wanting to root for the Go team because I see a lot of complaints about what Go lacks.  How about instead we sit down with the language for more than 1 hour so we can learn about the many, many other areas of what Go has gotten right.

I'm thrilled about a ton of things in Go, and starting to strongly agree with what I had heard, that Go makes programming fun again :-)

I also know C# and thought that was a nice language - I agree with your observations about overuse/abuse of generics though, and I'm not necessarily rooting for generics or any other specific feature.

For all the reasons I explained previously, I do hope a solution is found, eventually, that facilitates implementing things like basic math operations in a practical, useful general-purpose form - the fact that it can't be done in a satisfying way right now, is an indicator that something is still missing.

I am definitely rooting for Go for so many other reasons though - I'm already promoting it to everyone I know :-)

[Carlos Castillo]

It''s my belief that programmers shouldn't be adverse to programming. A solution of writing an if statement in-line, or a function for re-use in the current package, is not an unreasonable situation that needs to be fixed. 

[egon]

On Saturday, December 21, 2013 3:42:10 AM UTC+2, Rasmus Schultz wrote:

> I'm wanting to root for the Go team because I see a lot of complaints about what Go lacks.  How about instead we sit down with the language for more than 1 hour so we can learn about the many, many other areas of what Go has gotten right.

I'm thrilled about a ton of things in Go, and starting to strongly agree with what I had heard, that Go makes programming fun again :-)

I also know C# and thought that was a nice language - I agree with your observations about overuse/abuse of generics though, and I'm not necessarily rooting for generics or any other specific feature.

For all the reasons I explained previously, I do hope a solution is found, eventually, that facilitates implementing things like basic math operations in a practical, useful general-purpose form - the fact that it can't be done in a satisfying way right now, is an indicator that something is still missing.

Earlier in the comments there is a link to a good article by Rob Pike, http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html.

+ egon

[Rasmus Schultz]

Great article - spot on, really :-)

[Joshua Bowles]

"... nobody knew what programming was.... The most dangerous thought that you can have, as a creative person, is to think that know what you are doing. Because once you think you know what you are doing you stop looking around for other ways of doing things, and you stop being able to see other ways of doing things, you become blind...."

Assumptions about what modern programming languages SHOULD offer reminds me of something Brett Victor said in his presentation "The Future of Programming"(http://vimeo.com/71278954):