On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:

This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.

Discussing is (usually) fun :) [..]

Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).

Instead of throwing (and rescuing exceptions) all over the place (an approach I dislike), some typed languages offer a better way to deal with these situations: option types[1]. In a nutshell, an option type represents a value that could (or not) be nil. Lately I've been playing around with Elm and Rust and, in both cases, the compiler will complain if you do not write code to handle the "None" case. You can check some Rust[2] example if you are interested. And it looks like C++17 already support such a feature (although we are not using it IIRC). As a side note (about throwing exceptions), I prefer having "find_by_device_name" and "find_by_device_name!" methods. The former would return 'nil' if a device is not found and the latter would raise an exception. The idea is that the user of the library could decide how important is not finding a device, as it might be (or not) a critical error. But that's a different discussion. [..]

Both errors are the same error, a programmer error. Both errors happen during runtime, just the raised exception is different. In Ruby, the error is revealed in a slightly different way that it would be revealed in a static language. But that's the whole difference. Static type checking would not save you in 98% of the cases.

Proper static type checking might help in those situations.

What can save us in both cases? Comprehensive unit tests. Because they have a completely different goal from the checks performed by the compiler and they should spot a different kind of errors. Of course, that implies that whoever is writing the tests thinks in all possible situations (like the device not being there) and covers those situations with tests. That's why unit tests are a must in both dynamically and statically typed languages.

I absolutely agree. [..] On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value. Most of our bugs have nothing to do with type checking. If main argument against Ruby is that it lacks of type checking, I can live with that :) Regards, Imo [1] https://en.wikipedia.org/wiki/Option_type [2] https://rustbyexample.com/std/option.html -- Imobach González Sosa YaST team at SUSE LINUX GmbH Blog: https://imobachgs.github.io/ Twitter: @imobachgs

On Wed, Dec 13, 2017 at 07:36:19AM +0000, Imobach González Sosa wrote:

On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:

...

This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.

Discussing is (usually) fun :)

[..]

...

Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).

Instead of throwing (and rescuing exceptions) all over the place (an approach I dislike), some typed languages offer a better way to deal with these situations: option types[1].

In a nutshell, an option type represents a value that could (or not) be nil. Lately I've been playing around with Elm and Rust and, in both cases, the compiler will complain if you do not write code to handle the "None" case. You can check some Rust[2] example if you are interested.

And it looks like C++17 already support such a feature (although we are not using it IIRC).

I have that idea in mind (https://trello.com/c/Kjq05SDY/119-use-stdoptional-c17) but C++17 in SLE 15 is experimental.

As a side note (about throwing exceptions), I prefer having "find_by_device_name" and "find_by_device_name!" methods. The former would return 'nil' if a device is not found and the latter would raise an exception.

I always though the function with ! modifies the argument while the one without returns a modified object.

On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value.

I can remember bugs of the kind "undefined method xxx for nilClass". And I can also remember bugs where a function name was simply mistyped. ciao Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

V Wed, 13 Dec 2017 10:04:24 +0100 Arvin Schnell napsáno:

On Wed, Dec 13, 2017 at 07:36:19AM +0000, Imobach González Sosa wrote:

...

On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:

...

This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.

Discussing is (usually) fun :)

[..]

...

Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).

Instead of throwing (and rescuing exceptions) all over the place (an approach I dislike), some typed languages offer a better way to deal with these situations: option types[1].

In a nutshell, an option type represents a value that could (or not) be nil. Lately I've been playing around with Elm and Rust and, in both cases, the compiler will complain if you do not write code to handle the "None" case. You can check some Rust[2] example if you are interested.

And it looks like C++17 already support such a feature (although we are not using it IIRC).

I have that idea in mind (https://trello.com/c/Kjq05SDY/119-use-stdoptional-c17) but C++17 in SLE 15 is experimental.

...

As a side note (about throwing exceptions), I prefer having "find_by_device_name" and "find_by_device_name!" methods. The former would return 'nil' if a device is not found and the latter would raise an exception.

I always though the function with ! modifies the argument while the one without returns a modified object.

Well, it is only convention and such convention specifies that version with ! is "dangerous" function that e.g. modify object that someone else can use, raise exception if something is missing and so on. It is mainly used to distract between two versions of call ( e.g. similar to some degree to const and non-const versions of method in C++ ).

...

On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value.

I can remember bugs of the kind "undefined method xxx for nilClass".

sadly same kind of errors can happen also in ycp and c++ ( calling something on nil ) and at least for me result is the best from these three ( ycp silently do nothing and c++ segfault ). If we want to prevent this kind of errors, then rust is answer.

And I can also remember bugs where a function name was simply mistyped.

agreed. It is trade-off for dynamic nature of ruby. And for mistyped function names unit tests is currently only answer. In future ruby type inference can help.

ciao Arvin

Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

V Wed, 13 Dec 2017 10:31:32 +0100 Arvin Schnell napsáno:

On Wed, Dec 13, 2017 at 10:14:42AM +0100, Josef Reidinger wrote:

...

V Wed, 13 Dec 2017 09:47:13 +0100 Arvin Schnell napsáno:

...

On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa wrote:

...

This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.

Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language.

I think you are mixing static typing and static code analysis.

ciao Arvin

Well, it is a bit related as static code analysis strength is related to rigidness of language. And actually even c++ have quite weak static code analysis.

Not only the compiler can do static code analysis. Other tools do much more, e.g. coverity.

ciao Arvin

How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil. I know that mvidner trying rubylint and it was quite tricky. So if coverity can deal with such issue, we can check how it is done and can check is someone try similar approach for ruby and it can really helps us. Thanks Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On Wed, Dec 13, 2017 at 10:54:48AM +0100, Jiri Srain wrote:

In C++, you can follow the approach which Michael did when developing libzypp: Only use plain pointers for the minimum time needed to convert them to various kinds of smart pointers which the boost library offered. This policy somehow mitigated the problem with pointers.

Those smart pointers are standardised in C++11 and of course also used in libstorage-ng. ciao Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

V Wed, 13 Dec 2017 10:54:48 +0100 Jiri Srain napsáno:

On 13.12.2017 10:35, Josef Reidinger wrote:

...

V Wed, 13 Dec 2017 10:31:32 +0100 Arvin Schnell napsáno:

...

On Wed, Dec 13, 2017 at 10:14:42AM +0100, Josef Reidinger wrote:

...

V Wed, 13 Dec 2017 09:47:13 +0100 Arvin Schnell napsáno:

...

On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa wrote:

...

This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.

Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language.

I think you are mixing static typing and static code analysis.

ciao Arvin

Well, it is a bit related as static code analysis strength is related to rigidness of language. And actually even c++ have quite weak static code analysis.

Not only the compiler can do static code analysis. Other tools do much more, e.g. coverity.

ciao Arvin

How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil. I know that mvidner trying rubylint and it was quite tricky. So if coverity can deal with such issue, we can check how it is done and can check is someone try similar approach for ruby and it can really helps us.

In C++, you can follow the approach which Michael did when developing libzypp: Only use plain pointers for the minimum time needed to convert them to various kinds of smart pointers which the boost library offered. This policy somehow mitigated the problem with pointers.

Jiri

In fact it does not help always. E.g. now with libstorage-ng is there autoptr, but still we get segfaults when device graph is changed as these autoptr is set to NULL and create segfaults. So as long as program can have object that is no longer valid, you have problem to statically detect it as it means you have to understand code flow to decide if object is valid or not, which is really hard task for analyzer. As long as all objects are valid for its whole lifetime and no-one holds it after it is not valid it helps. BTW libzypp use quite heavily Null object pattern exactly to not return nil and instead this null object. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 13.12.2017 10:35, Josef Reidinger wrote:

How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil.

Coverity will (among a lot of other things) complain if you use a pointer that you got e.g. as a function parameter and didn't check it first before dereferencing it. Sometimes this will result in false positives, but an extra check is cheap and can indeed prevent a segfault. Kind regards -- Stefan Hundhammer YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

V Mon, 18 Dec 2017 11:57:49 +0100 Stefan Hundhammer napsáno:

On 13.12.2017 10:35, Josef Reidinger wrote:

...

How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil.

Coverity will (among a lot of other things) complain if you use a pointer that you got e.g. as a function parameter and didn't check it first before dereferencing it. Sometimes this will result in false positives, but an extra check is cheap and can indeed prevent a segfault.

Kind regards

If I get it correctly coverity report when pointer is assigned from unknown source ( e.g. that function parameter or its result ) and not checked? So it basically would like to see stuff a = method(); if (a) b = *a; or void m(char *c) { if !c return; ... } I think check like this can be done also for ruby, but I am not sure how much it will affect current code, because some methods can live with nil and some method require to not get it ( e.g. some private methods ). So I expect huge amount of false positives. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org