I don't know if any of that is true. The annotations actually help me to understand the code. I actually find it easy to rewrite and iterate with type annotations which are like machine checked comments. I think the purpose of the tool is to make it harder to write "bad" code, unless you mean "bad" in the aesthetic sense then I can't see how that is true either. In general I find it easier to write code since its easier to keep track of what the data looks like.
What do you mean by interfaces?
But then this is an argument that I don't have much time for and too much time has been spent on it already. Lets just say that if there are many major companies that felt the need to invest in a type system for a popular languages that don't have one, then there might be something too it.
With interfaces i mean the code you mingle with, like functions and methods. When you are half forced to read, at least the function signature, and or the manual, in order to understand and use it, it will lead to fewer bugs. The better you understand something, the more people reading it, the less bugs. And by-product you optimize for readability and comprehension.
I think a major reason why companies chose to invest in static typing is that so many developers are used to it coming from Java and other languages. Not necessary static typing itself, but the tooling that comes with it.
A type system is not a replacement for understanding. Where ever did you get that idea? The annotations help you to understand the code, they don't make it so you don't have to understand it.
I'd say python is about as popular as Java and so I don't see companies investing a bunch of money to make Java programmers more comfortable when they could just hire an army of Python developers if they wanted to. I just think they see value in the static analysis that types provide. Read about why Facebook added types to PHP they don't mention your hypothesis.
I don't mind programming in languages with dynamic type systems. I find it just as fun. But I do think its easier when there is a way to easily keep track of the type of thing being operated on. I mean the data is what is actually being operated on, the more I can tell about the data from reading the code the better. The most difficult systems I have ever worked on were the ones where unshaped globs of data were being shuffled around in hash tables and heterogeneous sequences. I would always have to use the debugger to find out what was going on at a given point. The code was dispatching on value and type. It was rough.
I think static typing is needed in a low, middle level programming language to help the optimizer, and make sure values doesn't go out of bounds. Fanny enough higher level languages like JavaScript (and probably python to, I don't know Python) are strictly typed eg. you can never go out of bound and get overflow errors, have dangling pointers, etc. When you already have strict typing, there's less need for static typing.
If the statically typed language is compiled to a dynamic language, you will lose most of the performance gains too, for example Dart is almost like JavaScript-with-static-typing, but it's twice as fast because the compiler can actually make use of the static types.
I also think static typing bolted on to a dynamic higher level languages do push you into an object oriented paradigm.
And I think the language becomes uglier with annotations.
And it makes people lazy so they name things x, y, z because the type annotation fills in the rest.
But who cares about syntactic preferences, code readability and naming things :) The real reason you use static typing is to catch bugs ... But the best way to catch bugs is to understand the code, and have many people read it. When I see less good programmers the workflow goes something like this:
-I want to do foo ... autocomplete ... fooBaz, fooBar, fooFoo ... hmm, what can I do with foo ... autocomplete ... foo.bar sounds like what I need, it takes a baz, new Baz() ... damnit how do I get rid of this null exception ...
I did what you suggested and looked up why Facebook created Hack, from a release post (1): "but still spend time looking up mundane method names in documentation"
They don't have time to read and understand code. :P
I sometime jokingly say "the code is the documentation". Jokingly because I know that is unacceptable, but I most of the time actually do mean it. :P
"We didn’t want to slow the PHP workflow, so we came up with a new approach to reconcile instantaneous feedback with type safety."
They addressed one of the issues with a compile step, eg slower feedback loop.
> They don't have time to read and understand code.
Where does it say that. It actually says the opposite quite clearly if you cared to post the whole quote and not just what supports what you would like it to.
> They addressed one of the issues with a compile step, eg slower feedback loop.
Can you explain to me how faster feedback from static types that they, a concept which the article reiterates again and again, leads to a slower feedback loop. Clearly the article and many more like it say that the feedback loop actually speeds up with static analysis since you don't have to run the code to get the feedback.
I'm not sure if you actually want to objectively reason.
It's not wise for me to continue the discussion if you are going to resort to mudslinging. I can not simply explain something at the sandpit level, especially not to someone in an highly emotional state.
[this part contains sarcasm]
If you read between the lines in the article, and I've read it in other Facebook articles too (between the lines), understanding code is a problem for Facebook, it's against their principle of "go fast and break things". Good that they are not into the self driving cars business :P
[/this part contains sarcasm]
Traditional web development is a bit different from traditional development with long compile times. In PHP for example, the code is evaluated on the go, for every request. Development goes like this: Make change in .php file, (upload the file), reload the browser to see what happened. If you add a type-checker between, before they see what happened, it will slow down the development process. This is how static types and type checking slows down development by adding a compilation step.
Facebook claim they fixed it, but it's still a concern that need to be addressed when adding static types to other interpreted languages.
I do acknowledge that tooling allows you to see type errors directly in the editor/IDE before you reload the browser.
You can however get that without static typing, via inference. (type annotation do make building such tool easier).
It's however likely that the bug would be discovered during the manual or automatic testing anyway, so you have to evaluate if the added complexity to dev-ops from changing the language to add static typing, and adding a compilation step, is actually worth it.
Actually the most common php workflow I've seen is: Edit php files directly in production, save, refresh. If you see a blank page (php syntax error, returs HTTP 500) start sweating and quickly check apache error.log.
Repeat until syntax error is fixed (and initial feature is implemented).
What do you mean by interfaces?
But then this is an argument that I don't have much time for and too much time has been spent on it already. Lets just say that if there are many major companies that felt the need to invest in a type system for a popular languages that don't have one, then there might be something too it.