View mode: basic / threaded / horizontal-split · Log in · Help
September 29, 2012
Re: Rust and D
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.
September 29, 2012
Re: Rust and D
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.
September 29, 2012
Re: Rust and D
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?
September 29, 2012
Re: Rust and D
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.
September 29, 2012
Re: Rust and D
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
September 29, 2012
Re: Rust and D
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."
----
September 29, 2012
Re: Rust and D
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?
September 29, 2012
Re: Rust and D
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
September 29, 2012
Re: Rust and D
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).
September 29, 2012
Re: Rust and D
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.
1 2 3 4
Top | Discussion index | About this forum | D home