For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem to agree that it's always superior to have a REPL than to be forced to live without.
Lots of people love programming in Golang (I especially love to write distributed systems with it!) yet it probably won't ever offer us a REPL. That must mean one of two possibilities are true, both of which are bizarre: either 1) we love Go in spite of being limited by not having a REPL, or 2) having a REPL isn't as big of a deal as everyone thought.
So I'd like to ask all of you: Do we love Go in spite of being held back by it? If so, then what are the factors that cause us to decide that using Go is worth giving up programming power? After all, each of us are choosing to use Go in lieu of more powerful languages. So why do we choose to give up programming power?
Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? That seems plausible. It's at least as plausible as "it's a good idea to give up REPLs for static typing."
Go is wonderful to work with. But I'm so confused why it feels wonderful to me. I know I love programming in it, but once I start thinking about the implications, I start to wonder: Isn't giving up power a bad thing, and therefore choosing to use Go == choosing to be forever held back by its deficits, and therefore it's a bad decision? Or is it true that having every possible language feature available to you ("maximum potential programming power," i.e. as far above Blub as possible) isn't as big a deal as we all thought?
This pg essay talks about why it's worthwhile to have as much power as possible: http://www.paulgraham.com/avg.html (search for Blub Paradox) .... So either he's wrong, or we're ignoring him even though he's right. Which is it?
EDIT: There are other limitations besides lacking a REPL, e.g. there's no dynamic typing. It seems like we should try to figure out why it's a good idea to give up any programming power at all.
[1] https://github.com/scala-ide/scala-worksheet/wiki/Getting-St...
I use small files instead of repls most of the time. There's no program that's too short to be stored in a file.
The current grandaddy is Devel::REPL - https://metacpan.org/release/Devel-REPL
The new kid on the block is Reply - https://metacpan.org/release/Reply
PS. I do find using a Perl REPL invaluable for me.
Given this focus, it sort of makes sense why you might not miss a repl as much in go (though personally I do still miss it). Repls are most useful for exploring and experimenting with complex data, while I think go's focus is more on streamlining and bulletproofing all the machinery surrounding the data than doing a whole lot with the data itself.
I don't mean this as a criticism and I'm not trying to say that you can't do serious data processing in go, just that it's not a core strength like it is in functional languages. I think the majority of applications out there actually have fairly light data processing needs and heavy glue needs, so go's set of tradeoffs make it a great candidate for tons of projects.
No, it's not. As long as you have a way to polymorphically print a return value, which there are ways around (in Go, with reflection; in Haskell, with typeclasses; in Java, with Object's toString), there is nothing semantically difficult about a REPL for statically typed languages.
> there's no dynamic typing
Yes, there is, through `interface{}`.
You could give a BMW M3 a faster engine, or a more full-featured Bluetooth sound system, but it's the way the steering wheel feels that makes people love that car. Same with Golang. They did an extraordinary job balancing the language, especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.
This one is perfect however, and really explains my feelings towards Go (and recently, C, oddly enough).
Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.
The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages).
There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's just not that useful when you have powerful IDE's at your disposal.
Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.
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
import pdb; pdb.set_trace()
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).
[1] http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).as...
[2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...
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).
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.
For java there is bean shell/groovysh which isn't quite as good.
There is a mono repl and there is linqpad for c#. Ive used linqpad and it is very usefull.
scala worksheets are also very cool.
This is why we Lisp developers have networked REPLs -- I can start up a remote JVM, in communication with other services, connected to my local vim session. I can dynamically load code into it, start and stop my application, etc, all from my editor.
C# ==> http://www.mono-project.com/CsharpRepl
C++ ==> http://root.cern.ch/drupal/content/cint
C ==> http://www.softintegration.com/demos/chstandard/interactiveC...
Java ==> http://www.javarepl.com/console.html
People, please pay attention in compiler design classes and don't mix languages with implementations.
I constantly use REPLs to experiment, verify output of functions, etc. In the case of Go I open the Go Playground at least once a day, often much more.
I often find myself exploring in a language with a good REPL and then implementing the findings in a language that does not.
If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.
When I mentioned state, I did not mean testing. Sure, a properly designed system will have all it's computaional parts abstracted in a functional way so it will be trivially tested compiled or not. However, REPL is incredibly useful during the development process when the abstractions required are not yet clear, so it allows one to easily explore design possibilities without committing signficant effort of implementing a correct compilable module.
A REPL is a nice learning tool, but actually not that useful for productive programming. Go has a playground for learning and experimenting.
I've made a live editor [1] for Go that I use very happily (and I keep working on a 2nd generation version, rewritten in Go, which will be more user-friendly to install and use).
There are other REPL-like tools like [2] and [3].
[1] https://github.com/shurcooL/Conception#demonstration