Re:Typed Lua: An Optional Type System for Lua [pdf]
by adamnemecek on Friday June 13, 2014 @05:07PM
(#7890841)
How do you determine the return value of a C function? You look at the function prototype. How do you determine the return value of a Python function? You have to read the whole thing. If you are working with large code bases, reading the whole thing is not really possible.
Re:Typed Lua: An Optional Type System for Lua [pdf]
by taeric on Friday June 13, 2014 @05:13PM
(#7890864)
You are just trying to make an appealing argument. This literally adds nothing to the debate. A simple survey of open source software would be more convincing. And even that wouldn't be definitive.
Re:Typed Lua: An Optional Type System for Lua [pdf]
by adamnemecek on Friday June 13, 2014 @05:50PM
(#7891025)
Where's the appeal in my argument? It was an example.
Re:Typed Lua: An Optional Type System for Lua [pdf]
by taeric on Friday June 13, 2014 @08:19PM
(#7891540)
It is an appeal to how logical the example seems. That is, it sounds like it would be applicable "at large." However, evidence seems to show that, "at large," it is mostly a non sequitor.
That is, you get better systems the more programmers you have that do have a good grasp on the whole system. Ironically, you have better arguments against knowing specifics of the system -- that is, at the individual function level -- than you do the high level picture. Consider, Linus knows the linux kernel better than I can really comprehend. I doubt he knows every function's return value.
What I have not seen, is evidence that any of your claims are true. I have seen easy to read programs in both dynamic and static languages. So far, I've seen very little correlation between the two as to which is desirable. The static languages are typically a bear on some algorithms because you have to provide so much more to the compiler for it to trust you. This does feel like it would lead to less bugs, but it goes against the "readable" and possibly the "more productive" ideas.