Am 06.11.2013 16:10, schrieb Russel Winder:
> On Wed, 2013-11-06 at 15:59 +0100, Paulo Pinto wrote:
> […]
>> Yeah, I am pretty old at this game. I already lost count how many
>> technologies I have used since 1986. :)
>
> 1986. You are a youngster then. ;-)
>

Started using computers at the age of 10, so 1986 - 10 ...

On Wednesday, 6 November 2013 at 16:24:12 UTC, Paulo Pinto wrote:
> Am 06.11.2013 16:10, schrieb Russel Winder:
>> On Wed, 2013-11-06 at 15:59 +0100, Paulo Pinto wrote:
>> […]
>>> Yeah, I am pretty old at this game. I already lost count how many
>>> technologies I have used since 1986. :)
>>
>> 1986. You are a youngster then. ;-)
>>
>
> Started using computers at the age of 10, so 1986 - 10 ...

1976? Man, you are a teenager then ;-)

On Wed, 2013-11-06 at 17:39 +0100, Bienlein wrote:
[…]
> 1976? Man, you are a teenager then ;-)

The year I went apesh!t when I found that the elliptic integral solver routines in the NAG library were broken. I idled away the time by creating idioms for writing abstract data type code in FORTRAN 66. Bizarrely, analogous tricks appear to be essential in JavaScript.

It was also the third year of listening to Dark Side of the Moon and the first year of Wish You Were Here which is much better.

But you didn't want to know this.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

06-Nov-2013 19:34, Jesse Phillips пишет:
> On Wednesday, 6 November 2013 at 07:02:20 UTC, Jonathan M Davis wrote:
>> Yikes. Sorting time in D is trivial. It would never occur to me that
>> that would be hard.
>
> I know, it's something I use. Something one probably expects to Just
> Work. I thought for sure Go would have provided the needed functions,
> but no they didn't.
>
> While I was trying to find additional information I came across this
> blog[1] which had such a fitting quote, "The sort package in Go is
> pretty neat." Directly followed by "there are some specific functions
> for sort some of the basic types."

I swear when I glanced at [1] I thought it was sarcasm. Reading it again - I see it wasn't :)

>
> When trying to write a blog which centers around the sort packaging
> being *the* example of why Go's lack of generics sucks, reading that the
> package is "neat" was not something I expected.
>
> 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html


-- 
Dmitry Olshansky

Am 06.11.2013 19:45, schrieb Dmitry Olshansky:
> 06-Nov-2013 19:34, Jesse Phillips пишет:
>> On Wednesday, 6 November 2013 at 07:02:20 UTC, Jonathan M Davis wrote:
>>> Yikes. Sorting time in D is trivial. It would never occur to me that
>>> that would be hard.
>>
>> I know, it's something I use. Something one probably expects to Just
>> Work. I thought for sure Go would have provided the needed functions,
>> but no they didn't.
>>
>> While I was trying to find additional information I came across this
>> blog[1] which had such a fitting quote, "The sort package in Go is
>> pretty neat." Directly followed by "there are some specific functions
>> for sort some of the basic types."
>
> I swear when I glanced at [1] I thought it was sarcasm. Reading it again
> - I see it wasn't :)
>

You will find lots of similar explanations from Go devotees when reading gonuts mailing list. :)

--
Paulo

On 11/6/13 5:38 AM, Russel Winder wrote:
> On Wed, 2013-11-06 at 08:26 +0100, Paulo Pinto wrote:
> […]
>> I rather use D than Go, but it has more to do with Go's community
>> with their religion decisions about generics, dynamic loading,
>> exceptions, enumerations, package management than anything else.
>
> I find the Go community excellent. The mailing list is only a small part
> of the community. Try coming to one of the monthly Go user group
> meetings in London.

Online fora are the universal place where the community meets.

> All communities are "religious". This D community takes religious
> decisions just as much as the Go, Scala, C++, etc. ones.

I disagree with this relativism that makes all language communities somehow idempotent. Programming languages' communities are very strongly influenced by their leaders. I'm friends with Walter so I can't be objective on that one, but let me just say his core values are well propagated within the community. I'll abstain to comment much about the Go community beyond this: it doesn't seem my cup of tea (even leaving aside technical issues).

> The position on
> generics is not strange if you understand the Go language, it's
> computational model and philosophy. Go is taking a non-standard
> position, but it is not wrong, it just means that approaches to
> algorithms you would take in Ada, C++, D, Rust, Java, Scala, etc. do not
> apply directly to Go. It is a shift of mindset and view. If this doesn't
> work for you, fine.

I also disagree with this "agree to disagree" that leaves everybody vacuously lukewarm. I think there are things that are just right and things that are just wrong. Go's team was unable to add generics to the language. That locks Go out of a variety of tools and techniques, which does not make it only "different", it effectively pauperizes the language leaving it the sole advantage that it's smaller. One non-technical current that I find quite difficult to like is that the Go proponents have not only shun generics, but effectively made it a politically incorrect topic in their community. All discussion on generics on the go forums are quickly shushed away.

>> Now for those of us that have become used to the niceties the
>> mainstream languages have adopted from academia in the last 30
>> years, Go feels a bit too light.
>
> But for those people seeking a native code language coming from Python,
> Go is a breath of fresh air where D, C++, etc. are claustrophobic
> language stuck in the attitudes of the 1970s.

Interesting. Why would be D in the same category with C++ 1970s-attidude-wise, and how is Go a breath of fresh air? If anything, the latter seems to me it kinda implements ideas that seemed cool in the 1970s, but nothing since.


Andrei

On 11/6/2013 5:38 AM, Russel Winder wrote:
> But for those people seeking a native code language coming from Python,
> Go is a breath of fresh air where D, C++, etc. are claustrophobic
> language stuck in the attitudes of the 1970s.

I know that D carries forward some attitudes from the 1980's, particularly in its orientation towards supporting the separate compilation model, its dependency on object file formats and standard linkers, etc.

But other than that I do not know what you mean about D.

On 11/6/2013 6:05 AM, Russel Winder wrote:
> Or are willing to be trained in. The problem is not the status quo in
> the organization, the problem is the intransigent inability to learn
> that far too many programmers seem to display. People should be wanting
> to use new technologies if available and appropriate. Of course the
> current language is a candidate and may be the right choice, it just
> shouldn't be assumed it is the only choice.

While your comment seems to be a commonsense truism, there are so many new things constantly coming out that one cannot possibly learn them all and pick the best, and even then there's another one that just appeared. It is not an unreasonable strategy to wait a bit and see which ones have staying power. Most don't, and in hindsight would have been a waste of time to learn.

On Wednesday, 6 November 2013 at 15:34:54 UTC, Jesse Phillips wrote:
> 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html

Hmm... if sort.Sort accepts a sortable interface, they could define those 3 methods for respective arrays so that they would satisfy the interface, and sort.Sort would accept them transparently. Well, if go allows extending array's interface.

On Wednesday, 6 November 2013 at 20:52:41 UTC, Kagamin wrote:
> On Wednesday, 6 November 2013 at 15:34:54 UTC, Jesse Phillips wrote:
>> 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html
>
> Hmm... if sort.Sort accepts a sortable interface, they could define those 3 methods for respective arrays so that they would satisfy the interface, and sort.Sort would accept them transparently. Well, if go allows extending array's interface.

It does not. A specific type must be created and the functions defined for it. Was one of the first WTFs I hit. It doesn't solve the lack of generics problem, which is much more important.