5 ms·
or rather, a language runtime that enforced some level of introspect-ability on everything And now we get to the real meat of it. It's not a REPL you want. I
by zzalpha 9y ago
or rather, a language runtime that enforced some level of introspect-ability on everything
And now we get to the real meat of it.
It's not a REPL you want.
It's reflection.
It just so happens that the latter is frequently paired with the former.
And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compiler, debugger, and IDE can do a much better job.
But as a feature it's orthogonal to a REPL.
- derefr 9y agoReflection isn't orthogonal to a REPL; it's synergistic with a REPL. When you have a static language, yes, REPLs don't add much; reflection by itself is all you need and an IDE will suit you fine. But when you are working in a language with runtime code generation—one where objects can build themselves new runtime-native function handles in response to messages—then a REPL will be able to do things for you that an IDE cannot†. A REPL in a dynamic language (that takes advantage of its dynamicity) can be used to "explore" down CORBA/DBUS object trees; or fluently walk REST or SOAP endpoints without needing pre-baked WSDL descriptors to guide you to them. Heck, an Erlang REPL can hot-upgrade remote nodes. :) † Or, at least, not a traditional IDE. You would need an IDE connected to a "live session" of your project—essentially a hybrid IDE-REPL. (Examples: Light Table; Emacs' CIDER extension for Clojure.)
- deleted 9y ago[deleted]
- pjmlp 9y agoLisp, Smalltalk and Mesa XDE at Xerox PARC are the genesis of what an IDE is supposed to be. Two dynamic and one static languages.