November 05, 2010
bearophile Wrote:

> Ellery Newcomer:
> 
> > hey, cool
> > 
> > stumbled on sing# a while ago and thought it was intriguing, or at least the fact that ms was using it to write an OS kernel
> 
> It contains a ton of new computer science ideas :-) So it's interesting regardless its applications. (If you don't keep yourself updated with new computer science ideas, you can't keep being a productive programmer for many years).

Are you saying that Walter Bright or anyone else here isn't as productive as you are because we haven't read about the latest language research done between 1980 and 2010? Keeping yourself updated with new ideas also means pragmatic real world books, not just ivory tower research papers that usually aren't freely accessible without an expensive subscription:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Martin/dp/0321712943/ http://www.amazon.com/D-Programming-Language-Andrei-Alexandrescu/dp/0321635361/ http://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208/ http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ http://www.amazon.com/Programming-Massively-Parallel-Processors-Hands/dp/0123814723/ http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/ http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ http://www.amazon.com/Version-Control-Git-Collaborative-Development/dp/0596520123/ http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/

Do I need to say more?
November 05, 2010
Pelle Månsson Wrote:

> On 11/05/2010 02:39 PM, Kagamin wrote:
> > bearophile Wrote:
> >
> >> Spec# adds only few things to C# 2.0:
> >> - Non-nullable types;
> >
> > It's hard to tell, whether they fix anything. When you cast nullable to non-nullable, you get your runtime exception as usual, if you if out access to nullable (e.g. in delayed method), you get your runtime exception again or rather logical bug.
> 
> Getting the error early is actually a lot better than getting the error late.

Getting the error early means that less code compiles and that makes the rapid development fail and turns it into a waterfall misery. It's important to make your tests run quickly in the background. One reason I prefer Python is that it let's me run even (semantically) buggy code, because syntactical correctness is enough. It really improves productivity.
November 05, 2010
On 2010-11-05 09:51:07 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> FWIW, I got word that nullable types are considered failure in C#'s design team. They were added in a haste and now the designers regret that.

But did they refer to nullable pointers or the ability to make regular value types (integers, etc.) nullable? These are actually two different things.
<http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx>

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

November 05, 2010
On 11/05/2010 02:48 PM, Gary Whatmore wrote:
> Pelle Månsson Wrote:
>
>> On 11/05/2010 12:43 PM, Gary Whatmore wrote:
>>> bearophile Wrote:
>>>> - A way to list what attributes are modified in a method (similar to my @outer).
>>>
>>> The compiler should do this itself.
>>
>> Doesn't make sense.
>>
>>>> My reference issue:
>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4571
>>>
>>> Walter, please close this as wontfix. We don't need those. These extra runtime checks will slow down my code. I know myself when my pointer is null.
>>>
>>>    - G.W.
>>
>> How, exactly, do you know when your references are null? Without
>> runtime checks, of course.
>
> Good code design makes the null pointer exceptions go away. I carefully ponder what code goes where. Simple as that. That language just introduces a boatload of unnecessary cruft in forms of runtime null checks. I don't need to know the exact temporal location of nulls, it's enough if the code takes care of handling it at run time.

Say you write a library, with a class and a function. Something like this:

class C {
    /* stuff */
}

void foo(C[] cs) {
    foreach (c; cs) {
        // do stuff with c
    }
}

How do you handle null, in this case?
November 05, 2010
Pelle Månsson Wrote:

> Getting the error early is actually a lot better than getting the error late.

OK, but it doesn't reduce the number of bugs. You had an error with nullables and you still has error with non-nullables.
November 05, 2010
On 11/05/2010 03:04 PM, Kagamin wrote:
> Pelle Månsson Wrote:
>
>> Getting the error early is actually a lot better than getting the error
>> late.
>
> OK, but it doesn't reduce the number of bugs. You had an error with nullables and you still has error with non-nullables.

But in the non-nullable version you actually know where the bug is, namely where you assign the null to the thing that shouldn't be null. The segfault can come from any unrelated part of the program whereto your null has slipped, at any later point in time.
November 05, 2010
On 11/05/2010 02:56 PM, Gary Whatmore wrote:
> Pelle Månsson Wrote:
>
>> On 11/05/2010 02:39 PM, Kagamin wrote:
>>> bearophile Wrote:
>>>
>>>> Spec# adds only few things to C# 2.0:
>>>> - Non-nullable types;
>>>
>>> It's hard to tell, whether they fix anything. When you cast nullable to non-nullable, you get your runtime exception as usual, if you if out access to nullable (e.g. in delayed method), you get your runtime exception again or rather logical bug.
>>
>> Getting the error early is actually a lot better than getting the error
>> late.
>
> Getting the error early means that less code compiles and that makes the rapid development fail and turns it into a waterfall misery. It's important to make your tests run quickly in the background. One reason I prefer Python is that it let's me run even (semantically) buggy code, because syntactical correctness is enough. It really improves productivity.

Yes, let's turn off compiler errors entirely!
November 05, 2010
Pelle Månsson wrote:
> On 11/05/2010 03:04 PM, Kagamin wrote:
>> Pelle Månsson Wrote:
>>
>>> Getting the error early is actually a lot better than getting the error
>>> late.
>>
>> OK, but it doesn't reduce the number of bugs. You had an error with nullables and you still has error with non-nullables.
> 
> But in the non-nullable version you actually know where the bug is, namely where you assign the null to the thing that shouldn't be null. The segfault can come from any unrelated part of the program whereto your null has slipped, at any later point in time.

I've always found it very easy to work out where a null came from. What I would hope from a non-nullable type is to eliminate rare code paths where a null can occur, which might not show up in testing.
November 05, 2010
Am 05.11.2010 15:27, schrieb Don:
> Pelle Månsson wrote:
>>  On 11/05/2010 03:04 PM, Kagamin wrote:
>>>  Pelle Månsson Wrote:
>>>
>>>>  Getting the error early is actually a lot better than getting the error
>>>>  late.
>>>
>>>  OK, but it doesn't reduce the number of bugs. You had an error with
>>>  nullables and you still has error with non-nullables.
>>
>>  But in the non-nullable version you actually know where the bug is,
>>  namely where you assign the null to the thing that shouldn't be null.
>>  The segfault can come from any unrelated part of the program whereto
>>  your null has slipped, at any later point in time.
>
> I've always found it very easy to work out where a null came from. What
> I would hope from a non-nullable type is to eliminate rare code paths
> where a null can occur, which might not show up in testing.

or better -> "how many UNTESTED null-able situations out there?" i think an enormous amount of code that just explodes when an null runs through it

good example is c# - because of (nearly) everything is nullable in c#
is see code like if( x != null ){ if( y != null ){ if( blub != null ... checks all day long, and if i don't see code like this does not mean that it is safer then...




November 05, 2010
On Fri, 05 Nov 2010 09:48:50 -0400
Gary Whatmore <no@spam.sp> wrote:

> Pelle Månsson Wrote:
> > 
> > How, exactly, do you know when your references are null? Without runtime checks, of course.
> 
> Good code design makes the null pointer exceptions go away. I carefully ponder what code goes where. Simple as that. That language just introduces a boatload of unnecessary cruft in forms of runtime null checks. I don't need to know the exact temporal location of nulls, it's enough if the code takes care of handling it at run time.

Good code design makes type errors go away. Just have a clear model of the app, carefully match your types with true notions of the domain. Simple as that. Who gets type errors, anyway? Do you? I don't.
It's just unnecessary load over the compiler dev team, isn't it? Let's get rid of that cruft!

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com