3 ms·

And this is one of the main reasons I massively prefer type annotations, statically analyzable languages and IDEs over dynamically typed languages, very loose l

And this is one of the main reasons I massively prefer type annotations, statically analyzable languages and IDEs over dynamically typed languages, very loose languages and plain text editors. Not being able to see what types code deals in, jump to definition, and find usages makes me feel crippled when exploring a new codebase. One of my wished for programmers everywhere is that tools like Github and BitBucket start analyzing projects and letting you navigate better. I think that could save thousands of engineer hours. This topic alone is a huge reason I started using Dart and eventually joined the team. Trying to figure out how a very large JavaScript codebase works is so incredibly painful, doing so in Dart is incredibly easy. This is also where very reflective libraries like Guice go wrong, and why, in my opinion, meta-programming should be used very carefully and sparingly.

omarhegazy 13y ago
Code navigation is hard in plain text editors, but definitely doable. I think the cost of setting up code navigation and jump-to-definition in Emacs is lower than the cost of dealing with how slow and bloated IDEs are. But, hey, to each his own. Although I think Light Table is trying to be like what you're saying, incredibly liberating in it's ability for code navigation. But it's still young. As for type annotation and static analysis ... you don't need to have static analysis for what you're talking about. Yes, static analysis works best for static languages, but you can have code auditing in dynamic languages. An auditor can dig through and profile your stuff while tests are running and learn about interactions between various entities in your code. And if you're doing anything in a dynamic language properly you're doing a lot of tests.
- spankalee 13y ago
  Having to analyze a running program increases the work and complexity for index code by an _incredible_ amount. When you can simply design a language in such a way as to be analyzable in the first place, I don't see why you'd want to require so much more work out of your tools, and especially your tool writers. Take my wish for Github to be more navigable. In a statically analyzable language they can run the analyzer and update their index on every commit. If they have to run tests then they have to basically add an entire continuous integration service which is a _lot_ more work, resources and security risk. Why make it harder than necessary?
  - omarhegazy 13y ago
    You're right. I guess I'm just a huge sucker for the whole dynamic languages with a REPL thing. I mean, Ruby is just so goddamn neat. The stuff that takes me 2 lines in Ruby can take me 10-15 in Java or C, and the difference only gets bigger as the program gets larger. Maybe I should try out static languages "done right" (type inference, etc.) before I give up on them.

omarhegazy 13y ago

Code navigation is hard in plain text editors, but definitely doable. I think the cost of setting up code navigation and jump-to-definition in Emacs is lower than the cost of dealing with how slow and bloated IDEs are. But, hey, to each his own. Although I think Light Table is trying to be like what you're saying, incredibly liberating in it's ability for code navigation. But it's still young. As for type annotation and static analysis ... you don't need to have static analysis for what you're talking about. Yes, static analysis works best for static languages, but you can have code auditing in dynamic languages. An auditor can dig through and profile your stuff while tests are running and learn about interactions between various entities in your code. And if you're doing anything in a dynamic language properly you're doing a lot of tests.

spankalee 13y ago
Having to analyze a running program increases the work and complexity for index code by an _incredible_ amount. When you can simply design a language in such a way as to be analyzable in the first place, I don't see why you'd want to require so much more work out of your tools, and especially your tool writers. Take my wish for Github to be more navigable. In a statically analyzable language they can run the analyzer and update their index on every commit. If they have to run tests then they have to basically add an entire continuous integration service which is a _lot_ more work, resources and security risk. Why make it harder than necessary?
- omarhegazy 13y ago
  You're right. I guess I'm just a huge sucker for the whole dynamic languages with a REPL thing. I mean, Ruby is just so goddamn neat. The stuff that takes me 2 lines in Ruby can take me 10-15 in Java or C, and the difference only gets bigger as the program gets larger. Maybe I should try out static languages "done right" (type inference, etc.) before I give up on them.