View mode: basic / threaded / horizontal-split · Log in · Help
September 29, 2012
Re: Rust and D
On 9/29/2012 5:05 AM, Peter Alexander wrote:
> 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.

Is it really? For example, all modern cars use fuel injection. That doesn't make 
carbureted cars unusable, I've driven them just fine for decades, but I sure do 
prefer fuel injection. Most people prefer it so much that you can buy fuel 
injection kits to replace the carburetors on most older cars.

I would not buy a new car with a carburetor.

Same goes for electronic ignition. Man, is that better than the old points/dwell 
system.
September 29, 2012
Re: Rust and D
On Saturday, 29 September 2012 at 17:03:33 UTC, Peter Alexander 
wrote:
>  I'm sure most people here have seen similar arguments against 
> D.

The complaint I've seen in a similar vain have been, "D is too 
complex" "it has everything and the kitchen sink" "if someone 
asks for it, it gets added"

And all but the last one is true. These are valid concerns and 
should not be dismissed as "people complaining to complain." 
Attempts to explain that to simplify the language introduces 
complexity to the code may fail. But the concern is not any less 
valid.

What is more annoying is that the level of understanding the 
complexity is usually attributed to that of C++. I grasp meta 
programming to a fairly decent degree, but I fail to read and 
understand that demonstrated in C++. I have very limited 
experience with C++ and almost no familiarity with templates 
(outside of the overlap with D). The syntax makes a huge 
difference! And with such clean syntax I guess our semantics is 
cleaner too.

A similar parallel I may have identified is Go return values. 
These are compared to those used in C. But if I picked up on this 
correctly, errors codes must be explicitly ignored. In which case 
I think of checked exceptions, except now every call is made with 
a try.

As you can see I am trying to apply experience I have with other 
languages to conform an understanding of the experience I'd get 
from Go. It doesn't mean it will be exactly correct, but this is 
how we efficiently eventuate things. If I have only ridden roller 
coasters that go upside-down, if asked whether I would enjoy one 
that doesn't go upside-down, I can apply my knowledge of the time 
spent not being upside down for those that do and make a best 
guess if I would find it fun/scary.
September 29, 2012
Re: Rust and D
On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright 
wrote:
> On 9/29/2012 1:08 AM, Peter Alexander wrote:
>> 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.
>
> I think that argument is making the claims that:
>
> 1. all features are equally valuable
>
> 2. if one can get by without a feature, then that feature is 
> not needed
>
> Both of those are invalid.

Exactly my thoughts. Templates enable abstraction. Go channels 
enable ... channels. Comparing both on the same level is 
ridiculous. Go has a vey low level of abstraction. I feel it is 
even worse than C. In C, void* can be a powerful abstraction 
tool, but in Go pointers are almost banned and made difficult to 
use. Empty interfaces do not cut it because they involve boxing 
and unboxing and they give you nothing that void * could not give 
you and easier. Interfaces in general? You cannot even sensibly 
define interfaces with methods that have that same interfaces as 
their return types (just try it). I cannot see Go being used 
beyond utf-8 text processing (web servers and the like). Numeric 
calculations? Without some serious abstraction tools nobody is 
going to waste their time. Other uses? Wherever you go 
abstraction (read generics and the like) rules. Not using 
abstraction means usually wasting your programming effort and 
redoing things multiple times. When people refuse to use 
programming languages without abstraction mechanisms it is 
exactly immagination that they use.
September 29, 2012
Re: Rust and D
On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright 
wrote:
> On 9/29/2012 1:08 AM, Peter Alexander wrote:
>> 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.
>
> I think that argument is making the claims that:
>
> 1. all features are equally valuable
>
> 2. if one can get by without a feature, then that feature is 
> not needed
>
> Both of those are invalid.

I'm not making claim 1, and claim 2 is true by definition.
September 29, 2012
Re: Rust and D
On 09/29/2012 09:12 PM, Walter Bright wrote:
> On 9/29/2012 3:54 AM, 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.
>>
>> All of those things are considered "a major thing" by their users, and
>> many
>> people do find them to "make a big difference."
>
> People can and do make those arguments and justifications.
>
> The question is, really, how large of a class of programming problems
> does each of those features address?
>

a) can be done in a library. (eg. in D, but not in Go) Therefore,
claiming that D does not have channels is moot anyway.
b), c) enable more powerful abstractions. They help all programs
if the programmer knows how to leverage them.
September 29, 2012
Re: Rust and D
On Sun, 30 Sep 2012 00:12:33 +0200
"Peter Alexander" <peter.alexander.au@gmail.com> wrote:

> On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright 
> wrote:
> >
> > I think that argument is making the claims that:
> >
> > 1. all features are equally valuable
> >
> > 2. if one can get by without a feature, then that feature is 
> > not needed
> >
> > Both of those are invalid.
> 
> I'm not making claim 1, and claim 2 is true by definition.
> 

Such a feature may not be *strictly* needed to accomplish a given task
within a given language. However, it may very well still be needed in
order to make said language actually worth switching to.

I can get by with conditional jumps instead of if/else blocks (ex:
Assembly, or old-school BASIC). And I even did for several years. But I
sure as hell won't anymore if I don't have to.

I, and many other people, find metaprogramming to be similarly "One
you try it, you don't want to leave it". Not only does Go not have
metaprogramming, but it doesn't even have the limited form of
metaprogramming, generics, that's already common in many other
languages. Therefore, the onus is on Go (or any other language that
lacks generics), to show that there's something about the langauge that
makes that sacrifice either worthwhile or at least somehow irrelevent.
September 29, 2012
Re: Rust and D
>> 1. all features are equally valuable
>>
>> 2. if one can get by without a feature, then that feature is 
>> not needed
>>
>> Both of those are invalid.
>
> I'm not making claim 1, and claim 2 is true by definition.

Brainfuck has all the needed language features by that definition.
September 30, 2012
Re: Rust and D
Go looks like a horrible combination of C and Lua, lacking the 
speed of C and the  power of Lua(and I'd bet LuaJIT beats Go for 
performance).

 Not all features are equal, for me, meta programming is such a 
useful thing that a language better have something damn 
impressive to replace it(especially a systems programming 
language). I scanned through the Rust docs and did not see 
anything that appeared capable of doing so.
September 30, 2012
Re: Rust and D
Looking at Rust's concurrency model, it does have some great 
ideas.
I wonder what would happen if D used thread-local heaps...

As far as syntax goes, the "shared" keyword could be used to 
distinguish between the heap types. I'm not sure how all this 
would work with "new", but I'm sure someone can think of a clean 
syntax.

In all, it's an intriguing idea, and it could fit with D's 
current concurrency model extremely well. I can definitely see 
this breaking code, but not much more than the switch to TLS 
globals did. It might be something to consider eventually.
September 30, 2012
Re: Rust and D
On 28-09-2012 19:42, 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?
>

Let me just clarify to everyone that Rust *does* have macros, which is 
certainly better than nothing at all: 
https://github.com/mozilla/rust/blob/master/doc/tutorial-macros.md

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home