Hacker News new | past | comments | ask | show | jobs | submit login

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.




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?


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: