The REPL and IDEs are somewhat orthogonal. IDEs are extremely limited in fact, as they can only rely on static-type info to infer meaningful stuff about how your software will behave. A REPL on the other hand is a runtime instance of your software that you can touch and interact with.
Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example, you can stop the execution at any point in your software and initialize the REPL, having complete access to the current context.
In Ruby it's as easy as:
require 'ruby-debug'; debugger
In Python it's as easy as the following (add IPython to the mix for extra awesomeness):
import pdb; pdb.set_trace()
I'm working with Scala lately and doing the above is a little painful, but I still work with the REPL a lot, in spite of also using IntelliJ IDEA as an IDE.
It's true that Java, C# or C/C++ don't have a REPL, but that's why I don't use Java, C# or C/C++ (or Go).
Well, it's difficult to see what a REPL is or does, if you're calling Visual Studio's "Immediate Mode" a REPL. It's not. It can evaluate simple expressions, but you can't type arbitrary code in it and hence you can't do arbitrary development in it, so it's not a REPL.
The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.
> The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.
So what?! Languages and implementations are not the same thing.
So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.
Basically, I don't care what the ideal implementation for a language X might look like in 10 years from now, what I care about is (1) what am I able to do with it right now and (2) what's the community's culture like?
Lately I've been learning some Clojure. I'm fascinated by how Clojure developers work with the source-code. Emacs is an extremely capable editor, but for Clojure it's a full-fledged IDE and a shell for the REPL and it can do anything you'd expect from an IDE. And the whole workflow is basically typing code, sending that piece of code for evaluation in the REPL, typing in the REPL some quick invocations to see how it works, rinse and repeat. The learning experience is also completely awesome, as for some reason you end up reading a lot of the standard library's implementation - coupled with the REPL on the other side in which to quickly type what you read - the workflow is amazing (though Smalltalk developers are probably laughing at me right now).
> So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.
Reference implementations only define languages that lack a proper ANSI/ISO/ECMA standard.
> though Smalltalk developers are probably laughing at me right now
Yes we are. :)
Emacs is a light version of a Lisp Machine. Now imagine how would your OS be, if everything would be as customizable as Emacs.
Sadly, Lisp machines and Smalltalk environments died on the mainstream.
Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example, you can stop the execution at any point in your software and initialize the REPL, having complete access to the current context.
In Ruby it's as easy as:
In Python it's as easy as the following (add IPython to the mix for extra awesomeness): I'm working with Scala lately and doing the above is a little painful, but I still work with the REPL a lot, in spite of also using IntelliJ IDEA as an IDE.It's true that Java, C# or C/C++ don't have a REPL, but that's why I don't use Java, C# or C/C++ (or Go).