October 03, 2009
Yigal Chripun wrote:
> On 02/10/2009 16:16, Jeremie Pelletier wrote:
>> Justin Johansson wrote:
>>> For the interest of newsgroups readers, I dropped in at the Cafe the
>>> other day and
>>> the barista had this to say
>>>
>>> http://cafe.elharo.com/programming/imagine-theres-no-null/
>>>
>>> Disclaimer: YMMV
>>>
>>> Cheers
>>>
>>> -- Justin Johansson
>>
>> Most of the bugs he expose are trivial to debug and mostly come from
>> beginners.
>>
>>  From the article:
>> "The distinction between primitive and object types is a relic of days
>> when 40 MHz was considered a fast CPU"
>>
>> I so disagree with that on so many levels. That's exactly what I believe
>> is wrong with programmers today, they excuse their sloppy programming
>> and lazy debugging with safe constructs which have way more overhead
>> than is actually needed. It doesn't really make the program easier to
>> code but the programmer less careful, leading to new kind of bugs.
>>
>> Maybe for financial or medical domains its acceptable since speed is not
>> an issue, but I expect my $3k computer to not slow down to a crawl
>> because its software is written in a "safe" way and I like people with
>> older computers to still be able to run my programs without waiting 5
>> minutes between any two mouse clicks.
> 
> all I can say is: Thank God I'm an atheist.
> it seems you do not want to hear a different opinion despite the fact that option types exist in FP for half a century already and provide the correct semantics for nullable types.
> 
> with your logic we should remove seat-belts from cars since it makes for less careful drivers.

I don't think you understood what I meant, seat-belts don't require you to buy a bigger car engine because they don't affect the performance of the car whatsoever. They're also not enforced, the car will run just as fine if you don't wear them.
October 03, 2009
Nick Sabalausky wrote:
> "Jeremie Pelletier" <jeremiep@gmail.com> wrote in message news:ha51v1$24ps$1@digitalmars.com...
>> Justin Johansson wrote:
>>> For the interest of newsgroups readers, I dropped in at the Cafe the other day and
>>> the barista had this to say
>>>
>>> http://cafe.elharo.com/programming/imagine-theres-no-null/
>>>
>>> Disclaimer: YMMV
>>>
>>> Cheers
>>>
>>> -- Justin Johansson
>> Most of the bugs he expose are trivial to debug and mostly come from beginners.
>>
>> From the article:
>> "The distinction between primitive and object types is a relic of days when 40 MHz was considered a fast CPU"
>>
>> I so disagree with that on so many levels. That's exactly what I believe is wrong with programmers today, they excuse their sloppy programming and lazy debugging with safe constructs which have way more overhead than is actually needed. It doesn't really make the program easier to code but the programmer less careful, leading to new kind of bugs.
>>
>> Maybe for financial or medical domains its acceptable since speed is not an issue, but I expect my $3k computer to not slow down to a crawl because its software is written in a "safe" way and I like people with older computers to still be able to run my programs without waiting 5 minutes between any two mouse clicks.
> 
> Holy crap, I feel like I have a clone ;)
> 
> (Hopefully that was original enough to rationalize a blatant "me too" post ;) )
> 

It certainly was, thanks :)
October 03, 2009
language_fan wrote:
> Fri, 02 Oct 2009 12:38:33 -0500, Andrei Alexandrescu thusly wrote:
> 
>> I'll note two things. For one, Walter is a heck more progressive than
>> his pedigree might lead one to think. He has taken quite some risks with
>> a number of features that made definite steps outside the mainstream,
>> and I feel he bet on the right horse more often than not. Second, this
>> particular discussion is not about efficiency.
> 
> I apologize that I said it in a way that might hurt Walter. I know he is extremely talented programmer and also open for new ideas. That is often not the problem. But it is not that hard to find features in D that are there only to make old C++ users feel comfortable. E.g. C style pointer syntax is harmful for the syntax of new features like tuples. It is also really confusing, but somehow has to be there since D "must" feel like C+
> +, otherwise someone would notice that D is actually a modern multi-
> paradigm language that allows even functional programming, which is a bit bad for the reputation in conservative c++ circles.

You will never be able to please everyone, or get everyone's attention. I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm.

Pointers are a critical feature of D, they allow both binary compatibility with C code and optimizations not possible without pointers. I use pointers all the time in D, just not nearly as much as I would in C/C++.

> Some people would not even touch the language with a 10 foot pole, if someone dared to provide a practical garbage collector library for it. Because that would mean that there are people with wrong opinions (tm) in the community. I know there is a old and stubborn language war between academic foofoo and "practical aspects".

Academics also seems to live in a fantasy world where code execute instantly and everyone in the world owns the latest computer hardware. They may not have a pet language but they have pet designs, which is quite equivalent.

There are conservative people on all sides :)
October 03, 2009
Andrei Alexandrescu wrote:
> Justin Johansson wrote:
>> For the interest of newsgroups readers, I dropped in at the Cafe the other day and
>> the barista had this to say
>>
>> http://cafe.elharo.com/programming/imagine-theres-no-null/
>>
>> Disclaimer: YMMV
>>
>> Cheers
>>
>> -- Justin Johansson
> 
> This article brings up a very interesting point that beats Walter's argument to a pulp, then puts salt on it.
> 
> Walter's overriding argument (I'm sure you know it, he repeated it claiming nobody understands it until we learned it by heart) was: "I don't want the compiler to require a value there! People will just put some crappy value in to get the code to compile, and the code with errors in it will soldier on instead of duly crashing! How is that better???" etc.
> 
> Yet D has structs.
> 
> Walter knows D has structs, and knows how D structs operate. He put structs in D because he thought structs, vegetables, exercising, and flossing are good for you.

We all know a serving of structs a day makes for healthy programmers!

> Yet structs operate the exact way that Walter claim is pernicious. Structs don't have a singular null value and always are nominally valid objects.

You're comparing value types to reference types. A class object is also always valid, its the reference that can be null by pointing to no object. You would have the same semantics by using struct pointers.

> Yet I've never heard Walter continuing his argument with "Just look at those stinky structs. It must be a million times I had a bug caused by the absence of null structs! I just had to put a crappy struct there in my code, and my code soldiered on in error instead of crashing!"

I never pass structs by value in D, except for returns because of RVO, so I can get a null struct pointer sometimes, but thats what contracts and backtraces are for. If my code was still executing on an invalid struct reference it would be much, much harder to pinpoint the origin of the bug.

> Why didn't he continue his argument that way? And why didn't anybody else continue his argument that way? Because nobody has had such a problem. Everybody uses structs, and everybody's happy about them lacking null.

Once again, structs are value types.

> To complete the irony, Walter and I discussed a while ago about structs and .init values. We concluded that D, at least for the time being, will allow struct construction without any code invocation, by just bitcopying the .init value of the struct over. He was very happy about that because a lot of code generation got majorly simplified that way. (I was less happy because that meant less user control over struct construction.) So Walter was happy that he had for structs a feature he thinks is amazingly dangerous for classes.

Classes have an initializer too, it's just copied by the GC after allocation instead.

> So I don't think Walter's argument is invalid, I think it simply doesn't exist. This post made it disappear.
> 
> 
> Andrei

I disagree, you compared apples to oranges here. Correct me if I'm wrong, but I don't think we should base an argument over reference types by using value types.

Jeremie
October 03, 2009
Jeremie Pelletier wrote:
> Andrei Alexandrescu wrote:
>> Justin Johansson wrote:
>>> For the interest of newsgroups readers, I dropped in at the Cafe the other day and
>>> the barista had this to say
>>>
>>> http://cafe.elharo.com/programming/imagine-theres-no-null/
>>>
>>> Disclaimer: YMMV
>>>
>>> Cheers
>>>
>>> -- Justin Johansson
>>
>> This article brings up a very interesting point that beats Walter's argument to a pulp, then puts salt on it.
>>
>> Walter's overriding argument (I'm sure you know it, he repeated it claiming nobody understands it until we learned it by heart) was: "I don't want the compiler to require a value there! People will just put some crappy value in to get the code to compile, and the code with errors in it will soldier on instead of duly crashing! How is that better???" etc.
>>
>> Yet D has structs.
>>
>> Walter knows D has structs, and knows how D structs operate. He put structs in D because he thought structs, vegetables, exercising, and flossing are good for you.
> 
> We all know a serving of structs a day makes for healthy programmers!
> 
>> Yet structs operate the exact way that Walter claim is pernicious. Structs don't have a singular null value and always are nominally valid objects.
> 
> You're comparing value types to reference types. A class object is also always valid, its the reference that can be null by pointing to no object. You would have the same semantics by using struct pointers.
> 
>> Yet I've never heard Walter continuing his argument with "Just look at those stinky structs. It must be a million times I had a bug caused by the absence of null structs! I just had to put a crappy struct there in my code, and my code soldiered on in error instead of crashing!"
> 
> I never pass structs by value in D, except for returns because of RVO, so I can get a null struct pointer sometimes, but thats what contracts and backtraces are for. If my code was still executing on an invalid struct reference it would be much, much harder to pinpoint the origin of the bug.
> 
>> Why didn't he continue his argument that way? And why didn't anybody else continue his argument that way? Because nobody has had such a problem. Everybody uses structs, and everybody's happy about them lacking null.
> 
> Once again, structs are value types.
> 
>> To complete the irony, Walter and I discussed a while ago about structs and .init values. We concluded that D, at least for the time being, will allow struct construction without any code invocation, by just bitcopying the .init value of the struct over. He was very happy about that because a lot of code generation got majorly simplified that way. (I was less happy because that meant less user control over struct construction.) So Walter was happy that he had for structs a feature he thinks is amazingly dangerous for classes.
> 
> Classes have an initializer too, it's just copied by the GC after allocation instead.
> 
>> So I don't think Walter's argument is invalid, I think it simply doesn't exist. This post made it disappear.
>>
>>
>> Andrei
> 
> I disagree, you compared apples to oranges here. Correct me if I'm wrong, but I don't think we should base an argument over reference types by using value types.
> 
> Jeremie

Save for address taking, value types are indistinguishable from immutable reference types. Value types don't have a null and that doesn't seem to make them unusable. It's a simple point.

Andrei
October 03, 2009
On Sat, 03 Oct 2009 10:32:28 -0400, Jeremie Pelletier wrote:

> I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm.

There has to be some limit on the amount of features a language can have before managing the complexity gets too large. Imagine that D 4.0 had 50 keywords more than D 2.0 currently has. Those features would make your code 5% faster. Would you still love D?

> Pointers are a critical feature of D, they allow both binary compatibility with C code and optimizations not possible without pointers. I use pointers all the time in D, just not nearly as much as I would in C/C++.

I did not argue against pointers, in general! Pointers can be useful but you do not need the C style syntax for declaring pointers to functions anywhere. I find it hard to read, especially after reading too much maths or functional code.
October 03, 2009
On 03/10/2009 16:09, Jeremie Pelletier wrote:
>
> I don't think you understood what I meant, seat-belts don't require you
> to buy a bigger car engine because they don't affect the performance of
> the car whatsoever. They're also not enforced, the car will run just as
> fine if you don't wear them.

I understood you quite well.

seat belts do not require a bigger car engine and compile time safety features do not add any overhead to run-time execution.

seat belts *ARE* enforced. they are required by law and you get a hefty fine if you violate this.

also, seat belts save lives and are used by regular drivers and car racers.
October 03, 2009
language_fan wrote:
> On Sat, 03 Oct 2009 10:32:28 -0400, Jeremie Pelletier wrote:
> 
>> I don't believe D is having some features merely to attract attention to
>> it, that's the thing I like best about D; it provides a very large set
>> of tools and let me choose how to use them, instead of enforcing a
>> certain model or paradigm.
> 
> There has to be some limit on the amount of features a language can have before managing the complexity gets too large. Imagine that D 4.0 had 50 keywords more than D 2.0 currently has. Those features would make your code 5% faster. Would you still love D?

Think of the english languages, how many words does it have? I would hate to try and express my ideas if I had only 100 words to choose from. Some people do but we call them simple minded or uneducated :)

Same for programming, D could have 100 keywords and be the most flexible language ever. Some would think its the best thing since sliced bread, others would only use the subset they're comfortable with, and a few would be scared away back to javascript.

People using a very limited subset of words to express their ideas tend to talk more to say less.

>> Pointers are a critical feature of D, they allow both binary
>> compatibility with C code and optimizations not possible without
>> pointers. I use pointers all the time in D, just not nearly as much as I
>> would in C/C++.
> 
> I did not argue against pointers, in general! Pointers can be useful but you do not need the C style syntax for declaring pointers to functions anywhere. I find it hard to read, especially after reading too much maths or functional code.

It makes writing C bindings that much easier, function pointers are mostly used for C code anyways since D has the much better delegate type.
October 03, 2009
On Sat, 03 Oct 2009 14:35:22 -0400, Jeremie Pelletier wrote:

> language_fan wrote:
>> On Sat, 03 Oct 2009 10:32:28 -0400, Jeremie Pelletier wrote:
>> 
>>> I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm.
>> 
>> There has to be some limit on the amount of features a language can have before managing the complexity gets too large. Imagine that D 4.0 had 50 keywords more than D 2.0 currently has. Those features would make your code 5% faster. Would you still love D?
> 
> Think of the english languages, how many words does it have? I would hate to try and express my ideas if I had only 100 words to choose from. Some people do but we call them simple minded or uneducated :)

Comparing spoken languages and formal languages used to program computers is rather far fetched. Even a small child recognizes more words than a complex programming language has keywords. There are programming languages with rather minimal set of core keywords and constructs. This makes them in no way more suitable for less intelligent people. And your stance of disagreeing with everyone here does not make you better than the rest of us, it is just irritating.

D is pretty verbose in many respects. There are some totally unnecessary words like 'body' in the grammar. Also things like foreach_reverse should just die. Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. Designing a crappy programming language is not hard. Usually the elegance arises from clever use of powerful, generic core structures.
October 03, 2009
language_fan Wrote:

> On Sat, 03 Oct 2009 14:35:22 -0400, Jeremie Pelletier wrote:
> 
> > language_fan wrote:
> >> On Sat, 03 Oct 2009 10:32:28 -0400, Jeremie Pelletier wrote:
> >> 
> >>> I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm.
> >> 
> >> There has to be some limit on the amount of features a language can have before managing the complexity gets too large. Imagine that D 4.0 had 50 keywords more than D 2.0 currently has. Those features would make your code 5% faster. Would you still love D?
> > 
> > Think of the english languages, how many words does it have? I would hate to try and express my ideas if I had only 100 words to choose from. Some people do but we call them simple minded or uneducated :)
> 
> Comparing spoken languages and formal languages used to program computers is rather far fetched. Even a small child recognizes more words than a complex programming language has keywords. There are programming languages with rather minimal set of core keywords and constructs. This makes them in no way more suitable for less intelligent people. And your stance of disagreeing with everyone here does not make you better than the rest of us, it is just irritating.
> 
> D is pretty verbose in many respects. There are some totally unnecessary words like 'body' in the grammar. Also things like foreach_reverse should just die. Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. Designing a crappy programming language is not hard. Usually the elegance arises from clever use of powerful, generic core structures.

Re foreach_reverse

People might remember that when I picked up D and joined this forum just some
3 or so weeks ago I made mention of being a Scala refugee.***  When asked what
I didn't like about Scala I commented about there being too many language constructs.
Someone here (maybe you, Fan?) consequently pointed out some of the superfluous
cruft like foreach_reverse in D.

I couldn't agree more; foreach_reverse should be euthanased by intralexical injection forthwith.

(***To be fair, my current interest is in non-JVM-hosted languages and I wouldn't be
using a minimalistic language like Clojure (also JVM hosted) either at the moment.)

> Even a novice programmer can write a meta-program to replace foreach_reverse
without any runtime performance hit.

I haven't had much time to investigate/learn meta programming facilities in D so I'm less than a novice in this respect.  If it's not too much trouble, Fan, please post your solution for replacing reverse_foreach with a meta-program; I know it sounds lazy of me, but your answer will save me precious time from having to RTFM.

Guessing its a recursive solution, and btw I am making use of opApply already in a small collection library that I'm messing with.

Cheers
Justin Johansson