Not Explicit • Hacker News Board

Re: Not Explicit

#11

Post by judofyr » Sat, Dec 30, 2017, 11:42 AM UTC

coderkd10 wrote: post #8

millstone wrote: post #5

I didn't agree with this article's definition of "explicit," which feels tautological: Rust is explicit because you can figure out a lot about your program from the source of it. But as long as the source code conveys the information, it is still explicit in the narrow sense I defined above. But if the thing will happen deterministically in a manner that can be derived from the source, it is still explicit in the nar…

> Source code conveys everything possible about your program in any language. I disagree with this statement. Behaviour of the program will be determined by machine instructions that the compiler generates for a given source plus the machine environment where these instructions will be run. And it is not guaranteed that the generated instructions will be same for a given source across different architectures and envi…

The behaviour is usually determined by language specification, and there are many machine instructions that can cause the correct behaviour. There are some cases where languages have machine-dependent behaviour, but most parts of most languages define the semantics independent of the machine it's running on.

> As far I understood, in the notion of explicitness that is defined in the article, it is defined that the language where source almost completely specifies the behaviour of program, irrespective of the compiler environments where it is compiled on, is an explicit language.

I've never seen anyone use this definition for "explicit". Most people use "explicit" to describe syntactical differences (e.g. "explicit vs implicit self/this"). "Implicits" in Scala is where the compiler inserts a method/function-call that didn't exist syntactically. The behaviour is still well-defined and not dependent on the machine instructions.

What you're describing sounds to me more about the language defining its own execution model that's abstracted above actual computers.

Re: Not Explicit

#12

Post by judofyr » Sat, Dec 30, 2017, 12:06 PM UTC

bad_user wrote: post #4

scribu wrote: post #2

What a useful breakdown! It seems like the narrow definition of “explicit” that the author uses is equivalent to “deterministic”. If that’s true, then “explicit” could always be replaced with a more precise alternative.

No, I don’t think that’s what the author is saying, but to make it clear the definition is: “In computer science, a deterministic algorithm is an algorithm which, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states” In turn what the author is saying is precisely what he says, no more, no less - explicit code is code whose behavi…

> In turn what the author is saying is precisely what he says, no more, no less - explicit code is code whose behavior you can understand just by reading it, with no external context, like how the runtime currently works on a particular hardware.

I'm not sure where this definition is coming from. Let's look at this code:

    vec.len()

I understand this behaviour very clearly. This will invoke the method given the following rules:

- Look for `len` on the type of `vec`

- If `vec` implements Deref it will look for `len` there

- Look for `len` on traits that the type of `vec` implements

- And so on…

Yes, the behaviour is conditional, but it's still well-defined and easy to understand, although complex.

"Implicit" is usually used when you want to describe situations where there are multiple interpretations, and one is chosen due to context. In Ruby:

    first_name + " " + last_name

In this example `first_name` can either be a local variable or a method call (which can either be in the same class, an included module, or a method_missing). Here it turns out it was a method call, and we therefore call this an "implicit method call". I can rewrite:

    self.first_name + " " + self.last_name

In this case there is a single interpretation: It can only be a method call.

However, while this code is explicit on whether or not it's a method call, it's not explicit about which method is being invoked. Usually this implicitness is considered a good feature since it allows abstraction, polymorphism and so on.

Re: Not Explicit

#13

Post by viraptor » Sat, Dec 30, 2017, 12:36 PM UTC

millstone wrote: post #5

I didn't agree with this article's definition of "explicit," which feels tautological: Rust is explicit because you can figure out a lot about your program from the source of it. But as long as the source code conveys the information, it is still explicit in the narrow sense I defined above. But if the thing will happen deterministically in a manner that can be derived from the source, it is still explicit in the nar…

>> but all of it is explicit if you look at the impl blocks for Vec.

> Well, all of Ruby's monkey-patching is explicit in the sense that you can find it if you know where to look.

There's a big difference. All impls in the first case can be found in a specific module and are listed in the generated documentation. If you want that information, there's one place to look.

In case of any monkey patching, that's not the case. It can happen literally anywhere, it can happen conditionally, and the code doesn't even have to mention the patched class since it can receive it as a parameter, which makes it impossible to even grep for.

Re: Not Explicit

#14

Post by __s » Sat, Dec 30, 2017, 12:50 PM UTC

millstone wrote: post #5

I didn't agree with this article's definition of "explicit," which feels tautological: Rust is explicit because you can figure out a lot about your program from the source of it. But as long as the source code conveys the information, it is still explicit in the narrow sense I defined above. But if the thing will happen deterministically in a manner that can be derived from the source, it is still explicit in the nar…

Your example comparing to C++ is something where I think the point of this article is coming out: we can become more explicit about what we're talking about when we bring nuance into our language to describe things like 'local' vs 'statically determined' which in language design discussions are both being labelled 'explicit' despite being distinct concepts. Explicit has been overused to the point of being a bad word

Re: Not Explicit

#15

Post by gravypod » Sat, Dec 30, 2017, 1:38 PM UTC

What bothers me about languages like Rust, which I think I'm in the minority on, is the lack of explicit type declarations.

C and Java, my two first languages, strictly spell out what types they expect. Sure you can ignore those rules but as long as you don't those types convey a lot of useful information about your program. With languages like Rust I don't think I could ever start writing code in them without an IDE. The entire idea of compiler-specified types is neat but I don't think all of your code should rely on that.

One oddity is Python which I have used a lot. The only difference is that Python is much less strict than the languages I'm used to. Because of this learning Python was still relatively difficult (Why is all the documentation written like a book!? I miss my Doxygen) but I didn't need an IDE.

Re: Not Explicit

#16

Post by twic » Sat, Dec 30, 2017, 1:57 PM UTC

gravypod wrote: post #15

What bothers me about languages like Rust, which I think I'm in the minority on, is the lack of explicit type declarations. C and Java, my two first languages, strictly spell out what types they expect. Sure you can ignore those rules but as long as you don't those types convey a lot of useful information about your program. With languages like Rust I don't think I could ever start writing code in them without an IDE…

In Rust, you still have to declare types for function parameters and return values. So, if you prefer to declare types everywhere, break your code down into single-expression functions!

Re: Not Explicit

#17

Post by jopsen » Sat, Dec 30, 2017, 1:59 PM UTC

viraptor wrote: post #13

millstone wrote: post #5

I didn't agree with this article's definition of "explicit," which feels tautological: Rust is explicit because you can figure out a lot about your program from the source of it. But as long as the source code conveys the information, it is still explicit in the narrow sense I defined above. But if the thing will happen deterministically in a manner that can be derived from the source, it is still explicit in the nar…

>> but all of it is explicit if you look at the impl blocks for Vec . > Well, all of Ruby's monkey-patching is explicit in the sense that you can find it if you know where to look. There's a big difference. All impls in the first case can be found in a specific module and are listed in the generated documentation. If you want that information, there's one place to look. In case of any monkey patching, that's not the…

So the definition of explicit or not has to do with the computability of the question.

Method resolution is not computable in a dynamic language with monkey patching. Hence, not explicit.

That's a good point.

Re: Not Explicit

#18

Post by oblio » Sat, Dec 30, 2017, 2:25 PM UTC

gravypod wrote: post #15

What bothers me about languages like Rust, which I think I'm in the minority on, is the lack of explicit type declarations. C and Java, my two first languages, strictly spell out what types they expect. Sure you can ignore those rules but as long as you don't those types convey a lot of useful information about your program. With languages like Rust I don't think I could ever start writing code in them without an IDE…

I have bad news for you, local type inference is coming to Java :)

Re: Not Explicit

#19

Post by hyperpape » Sat, Dec 30, 2017, 2:38 PM UTC

gravypod wrote: post #15

What bothers me about languages like Rust, which I think I'm in the minority on, is the lack of explicit type declarations. C and Java, my two first languages, strictly spell out what types they expect. Sure you can ignore those rules but as long as you don't those types convey a lot of useful information about your program. With languages like Rust I don't think I could ever start writing code in them without an IDE…

Interestingly, even Java is probably going to introduce local variable type inference using syntax somewhat like

    let foo = bar();

http://openjdk.java.net/jeps/286

Re: Not Explicit

#20

Post by wgjordan » Sat, Dec 30, 2017, 2:53 PM UTC

octothorpes wrote: post #3

It is worrying that you have to explicitly/verbosely write article about explicitness, I thought people knew.

To the contrary, the article about _implicitness_ is the one that doesn't need to be written because people already know what it means.