3 ms·
Not a lot of comments so far, but a few people are talking about stuff that is in the general vein of better tooling and code generation/automation through deep
by IceDane 8y ago
Not a lot of comments so far, but a few people are talking about stuff that is in the general vein of better tooling and code generation/automation through deeper code understanding by our tooling.
I think that this sentiment is interesting, because the way I see it, this can only happen if we continue the trend of transitioning to static typing.
We can't really do much more for dynamic language tooling today than we are already doing unless we solve the halting problem. The very nature of the problem (of providing smarter tooling) requires us to be able to gather metadata about our code, without having to execute it. This means static information.
We have invented all sorts of schemes circumvent this problem, like the plethora of documentation generation tools that exist. Of course, there is more to documentation than just information about the types of the arguments of functions and such, so documentation tools will always have their place. But I contend that a large part of the benefit a lot of the documentation provides for many languages is simply typing information.
And I also believe that with well engineered type systems and API typings, the types themselves can provide enough information to use a lot of APIs without having to reach for external documentation.
Or to paraphrase: in any code documentation generation tool for a dynamic language, there is a half-finished implementation of a badly formalized, insufficiently powerful static type system.
Typescript's huge rise in popularity seems to suggest that a lot of people used mostly to dynamic languages really wanted static typing all this time but just didn't know.
I think if we could combine some of the concepts of typescript with Haskell's type system, so that we can have both nominal and structural typing, we would have power to challenge the gods.
If we are able to harness all the information in such a type system, we could provide very powerful tooling that will basically be able to write code for us, as long as the types are right (automatically filling typed holes).
I am obviously a proponent of static typing, but I'd be interested in hearing if there's someone on the other side of the fence that has some ideas for how we can improve upon dynamic language productivity without solving the halting problem.
- bjourne 8y agoStatic typing is in my opinion the lazy language designer's way out. Yes, it allows for some introspection but only because the programmer has to type in all this type information! In 2019, we can do so much better. For example, development consists of typing some code, running it, typing some more, running it again and so on. The run time likely already guesses (correctly) the types of most variables for optimization purposes. But then this information is thrown away for no good reason. It can trivially be reused to provide context-sensitive auto-completion and other features. In general, why is editing, compilation and running still treated as three separate steps? Clearly, a lot of information could flow from each step to the other. It's not like a programmer compartmentalizes the job in that way. To him or her its one task which is to write software. And why on earth do we tolerate editors that doesn't know what a "size" is? Every half-decent programmer knows "size" is a positive integer. Just as we know that "filename" is a string, "temperature" a real and "is_complete" a boolean value. But the editor doesn't. When I write mail_recepient for the umpteenth time it doesn't even try to help me! There is so much low-hanging fruit here just waiting for someone to make better.
- softshellack 8y agoYou should google "hindley milner"
- quickthrower2 8y agoAnd refinement types
- sgillen 8y agoAs to your last point those variables could be anything, even in the simple examples you list. Size could be a tuple with the shape of some multidimensional thing, it could the the string "Large" temperature could also reasonably be a string "45C".
- bjourne 8y agoYes, it "could" be anything. But in practice it rarely is anything other than one easily guessed thing. Which is why Google's V8 work so well. Variable names is one signal that can be used to enhance the accuracy of these guesses.