On Saturday, 29 September 2012 at 06:11:30 UTC, Nick Sabalausky wrote:
> (Had to look up that name) Ahh, I see. That explains the dismissal of
> metaprogramming and generics, and the dismissal Go's objectors
> via a roundabout strawman (Ie by complaining about the act of
> complaining, and by categorizing of Go's complaints as merely
> programmers loving to complain for the sake of complaining).
>
> (And yea, I see the "[generics] are a fine thing", but he's still
> overall very dismissive of their importance.)

He's not dismissive of their importance. The point was that if you can dismiss a language based solely on its lack of generics then you are essentially admitting that you have very little imagination as a programmer. You are admitting that the only way you can do productive, meaningful work is if you have generics.

It's worth pointing out that a large fraction of (most?) programming languages do not have generics, yet people seem to be able to do meaningful work in them.

I imagine that the less imaginative hardcore Go programmers will look at D and say things like "wow, how can D programmers work without channels?", and maybe the Lisp programmers say "wow, how can D programmers work without homoiconic representation", and maybe the Haskell programmers say "wow, how can D programmers work with only crappy local type inference?"

As you can see, no matter what you think of these features, the arguments are pointless because it is very clear that you can do meaningful work without them. We get by without channels, homoiconicity, and full program type inference; just as the Go programmers get by without generics.

On Sat, 29 Sep 2012 10:08:29 +0200
"Peter Alexander" <peter.alexander.au@gmail.com> wrote:
> 
> He's not dismissive of their importance. The point was that if you can dismiss a language based solely on its lack of generics

Goes back to my other original point:

---------------
2. [He's dismissing] The impracticality of judging the myriad of languages out there these days by going hands-on with all of them, and not having some way to narrow things down to a realistic level first.
---------------

If he were talking about some minor insignificant feature, then I agree it'd be goofy to reject a language solely because of that. But that's not what's happening. Generics are a major thing. Many people *do* find them to make a big difference.

So there's three possibilities:

A. As I said, he's dismissing the impracticality of judging the myriad of languages without having some way to narrow things down to a realistic level.

Or he acknowledges that impracticality and:

B. He considers generics fairly unimportant/insignificant (ie, to the
point of feeling it's not worth using to narrow down language
choices), in which case *many* people clearly disagree with him. But
instead of addressing *that*, or even acknowledging it at all, he's
pulling a strawman with "They all just hatin' 'cause they like ta hate!"

C. He agrees that generics are a major thing that make a big
difference, in which case...what's he even complaining about?
Just being sore that his language isn't up to snuff? Or sore that
everyone doesn't have time to try out his "wonderful except for the
lack of generics" language?

So any way you take it, he's still not making much sense.

> then you are essentially admitting that you have very little imagination as a programmer. You are admitting that the only way you can do productive, meaningful work is if you have generics.
> 

Ok, yes, he is saying that too, but it's a ridiculous point and a
faulty argument. (See below.)

> It's worth pointing out that a large fraction of (most?) programming languages do not have generics, yet people seem to be able to do meaningful work in them.
> 

Still a pointless argument.

Name *any* feature X of a programming language and remove it: As
long as it doesn't render the language non-turing-complete or eliminate
the possibility of doing any I/O, then I can do useful things with the
language, and so can just about any other decent programmer. So sure,
that's true, he's right about that much.

Problem is, that's irrelevant: The important point he's missing is
"If feature X is helpful, then why should I *bother* going
without, when there are plenty of other languages (such as the one I'm
already using) that *do* provide me with that benefit?"

He fails to even *try* to answer that and instead just complains about complaining.

So unless he's trying to say "You should try Go because it's not worse than some languages", then his argument is a strawman.

Frankly, I'm getting the feeling he's frustrated at discovering that a feature-light language and initial "Wow, a Google/Pike language!" attention aren't enough to sell huge crowds of people on Go. And at the realization that to get a large following, and better PR, he needs to compete better on features.

On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky wrote:
> If he were talking about some minor insignificant feature, then I agree
> it'd be goofy to reject a language solely because of that. But that's
> not what's happening. Generics are a major thing. Many people *do* find
> them to make a big difference.

So, with this in mind, do you think these hypothetical people are all justified?

(a) [Go programmer]: D is rubbish because it doesn't have channels.
(b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity.
(c) [Haskell programmer]: D is rubbish because it doesn't have full type inference.

All of those things are considered "a major thing" by their users, and many people do find them to "make a big difference."

My question to you: Is it okay to reject D solely with these arguments? If not, how is this any different from rejecting Go solely from its lack of generics?

On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky wrote:
> Problem is, that's irrelevant: The important point he's missing is
> "If feature X is helpful, then why should I *bother* going
> without, when there are plenty of other languages (such as the one I'm
> already using) that *do* provide me with that benefit?"
>
> He fails to even *try* to answer that and instead just complains about
> complaining.

The answer to that question is obvious: you should bother going without because other languages provide other things that your pet language does not (e.g. channels + simplicity in this case).

Searching for a better language is a search like any other. Hill-climbing is a poor search heuristic. Sometimes you have to be willing to lose features to find the higher peaks.

On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander wrote:
> On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky wrote:
>> If he were talking about some minor insignificant feature, then I agree
>> it'd be goofy to reject a language solely because of that. But that's
>> not what's happening. Generics are a major thing. Many people *do* find
>> them to make a big difference.
>
> So, with this in mind, do you think these hypothetical people are all justified?
>
> (a) [Go programmer]: D is rubbish because it doesn't have channels.
> (b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity.
> (c) [Haskell programmer]: D is rubbish because it doesn't have full type inference.
>
> All of those things are considered "a major thing" by their users, and many people do find them to "make a big difference."
>
> My question to you: Is it okay to reject D solely with these arguments? If not, how is this any different from rejecting Go solely from its lack of generics?

Because except for Go, all static languages developed after 1990, which managed to gain mainstream use, have some form of generics.

Just to name a few out of my mind:

- Ada
- Modula-3
- Eiffel
- C++
- D
- Java
- VB.NET
- Object Pascal/Delphi
- Ocaml
- F#
- Haskell
- Scala

For those like myself that use C++ since the 'C with classes' time, Go's lack of generics feels like time travel into a time where generics were some strange stuff in compiler design papers.

The days when C++ compiler vendors used to offer C macro processor hacks, or external tools to enable the use of fake generics in C++ code. Borland was one of them, for example.

Funny enough, this type of tooling seems to start appearing in the Go community, proving that regardless of what they say, the need is there.

--
Paulo

On Saturday, 29 September 2012 at 11:18:40 UTC, Paulo Pinto wrote:
> On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander
>> My question to you: Is it okay to reject D solely with these arguments? If not, how is this any different from rejecting Go solely from its lack of generics?
>
> Because except for Go, all static languages developed after 1990, which managed to gain mainstream use, have some form of generics.

There's two ways to interpret this sentence:

1. You claim it is okay to reject Go because it differs from other statically typed languages, or
2. You claim that all statically typed languages must have generics to be worth using.

I hope it is not 1, and if it is 2 then again, I find this incredibly unimaginative.

Interestingly, Rob Pike comments on this world view:

http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html
----
"Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.

To be fair he was probably saying in his own way that he really liked what the STL does for him in C++. For the purpose of argument, though, let's take his claim at face value.

What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.

But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.

That's the detail that sticks with me."
----

On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander wrote:
> So, with this in mind, do you think these hypothetical people are all justified?
>
> (a) [Go programmer]: D is rubbish because it doesn't have channels.
> (b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity.
> (c) [Haskell programmer]: D is rubbish because it doesn't have full type inference.

Would you agree D would be better if it had those features?

How about we rephrase to something less inflammatory:
 [Go programmer]: I prefer not to use D because it doesn't have channels.
 [Lisp programmer]: I prefer not to use D because it doesn't have homoiconicity.
 [Haskell programer]: I prefer not to use D because it doesn't have full type inference.

Suddenly they all seem like perfectly acceptable arguments. If a person really likes/needs a certain language feature, then surely that is a good reason to reject a language that does not have this feature?

Many people like generics. Go doesn't have them. So why get angry if these people reject Go?

On 9/28/12 5:54 PM, Peter Alexander wrote:
> On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:
>> The Rust website says this:
>>
>> Generic types yes, only simple, non-turing-complete substitution
>>
>> After seeing that I just assumed the language was worthless and
>> ignored it.. is there something more to this?
>
> Relevant:
> http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagination.html

I remember the entry, it's caused some criticism on reddit or HN a while ago. Particularly the closing paragraph has grated many people, but heck, who hasn't had a bad blogging day?

We've experienced some similar criticism about D, which was quite clearly (in my opinion) a rationalization of a foregone disposition rather than a valid concern. One example that comes to mind is an email exchange with a C++ expert who latched onto D not supporting structs with internal pointers as an essential feature for many designs, which that person found unthinkable to adjust.

(I don't see how the parallel with the actress anecdote holds, as the punchline there is that an actor has to imagine being in other lines of work as the very part of acting.)

Anyhow, I've recently decided to acquire some fluency in Go and look into alternative ways to accomplish things I'd want to accomplish.


Andrei

On Saturday, 29 September 2012 at 12:09:35 UTC, Thiez wrote:
> Would you agree D would be better if it had those features?

Maybe. Maybe not. It's irrelevant.


> How about we rephrase to something less inflammatory:
>  [Go programmer]: I prefer not to use D because it doesn't have channels.
>  [Lisp programmer]: I prefer not to use D because it doesn't have homoiconicity.
>  [Haskell programer]: I prefer not to use D because it doesn't have full type inference.
>
> Suddenly they all seem like perfectly acceptable arguments. If a person really likes/needs a certain language feature, then surely that is a good reason to reject a language that does not have this feature?

If the person has not even tried the language then no, I still do not think those are valid reasons to reject a language.


> Many people like generics. Go doesn't have them. So why get angry if these people reject Go?

I like ice cream. Vegetables don't contain ice cream. So why get angry if I don't try vegetables?

Ok, so there's no reason to get angry, but I'd be an idiot to follow that logic.

The parallel is that I would consider it unhealthy to dismiss a language without trying it just because it lacks a feature that you happen to like. It may have something else that you like even more, or you may even find that the *lack* of a feature actually makes the language simpler and more expressive in ways you couldn't imagine (e.g. D's lack on inner struct pointers makes things significantly simpler).

On Sat, 29 Sep 2012 08:15:56 -0400
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
> (I don't see how the parallel with the actress anecdote holds, as the punchline there is that an actor has to imagine being in other lines of work as the very part of acting.)
> 

I'd been thinking the same thing. It was very amusing in the actress context, but brining it into programming just didn't seem to fit.