One of the best ways to get people to support optional typing in dynamic languages is to make sure their tools can read those types and provide metadata.
Program verification is cool, but enabling "intellisense" on a hash is even cooler.
Program verification is cool, but enabling "intellisense" on a hash is even cooler.
Happily, by the time I got around to working at a company like that, somebody had written Merlin which does not need anything like that. It even worked with js_of_ocaml, which was very impressive. I thought it was a very good tool.
[2]: http://kiwi.iuwt.fr/~asmanur/blog/merlin/
Emacs also has good support for a few other languages. Haskell has ghc-mod[3] and scion[4], for example.
[3]: http://www.mew.org/~kazu/proj/ghc-mod/en/
[4]: https://github.com/nominolo/scion
Similarly, there is ENSIME[5] for Scala.
[5]: https://github.com/aemoncannon/ensime
You can also use eclim[6] with Emacs, which integrates with Eclipse to offer rich functionality for Java.
[6]: https://github.com/senny/emacs-eclim
Of course, Emacs has language-aware editing for Emacs Lisp by default :). You can get similar support for most other popular dynamically typed languages as well.
So yes, Emacs does support plenty of languages like that, although almost always through a plugin. Happily, with the new package manager, installing and managing plugins is now trivial.
It's basically the same UX as you're used to in Java, except the info comes from asking the running process, rather than parsing statically.
If the parser error recovery is decent (and there is some effort put into this in most substantial front ends, since it's key to good error messages in large projects with long compile times, where recompile on every error fix isn't a great experience), the code doesn't need to be in a good state.
I've found that most IDEs support two kinds of compilers: the compiler used to generate code and find type errors, and a "presentation" compiler to provide interactive feedback that is error tolerant and can run in incomplete contexts. Java works this way, Scala worked this way (at least when I was working on the plugin), C# has a lot of infrastructure separate from the compiler to support its use in Visual Studio. A lot of work goes into this infrastructure beyond "writing a decent compiler," and emacs very simple language-aware interface didn't seem to support it very well (when I looked ~8 years ago).
It is how the Delphi compiler works in the IDE. I used to work for Borland, then Embarcadero, on the compiler front end.
When the compiler is running for code completion (kibitz mode, it calls it), it does a lot less work. No codegen, no type analysis of function bodies (begin / end blocks are entirely skipped), unless the cursor location is discovered to be inside a function body, whereupon the it rewinds and does more complete analysis. Normally takes no more than a few milliseconds to finish.
The word "hash" a shorthand for the noun-phrase "hash code" (aka "digest") and a verb for the process of creating hash codes.