51–60 of 77 posts
Programming in a language lacking a repl is always uncomfortable. I always wind up making a 'scratch.{ext}' file and running it to test things (scratch.* is in my global gitignore). Happy an interpreter+repl now exists for Go.
I use the go playground for this. Only problem I have run into is lack of sane time values.
Yaeji is going to be very happy that an interpreter was named after her! https://soundcloud.com/kraejiyaeji
Earlier quoted context omitted.
You can do similar things by writing tests as you go, plus then you can keep the tests if they seem useful.
For one meaning of "test", sort of, but repls are useful for far more than "do outputs match what I expect". Test writing is not very good for exploratory programming.
Why would I need a Go Interpreter? What advantage does it provide over using a precompiled binary?
Playing around, it seems to have problems assigning int literals to int8 variables, and it seems to sometimes have problems re-assigning pointer values.
Why would I need a Go Interpreter? What advantage does it provide over using a precompiled binary?
In a "scripting" scenario, you can load some golang code at runtime without needing to bring the full golang compiler toolchain along, which keeps the nice "single binary" deploys of golang. It may be possible to sandbox scripts as well (though I haven't looked into how that could work with this implementation), which could reduce the risk of running scripts (less likely to shoot yourself in the foot. Probably not a security boundary -just look at how much work goes into safe JS in browsers to have that).
Why would I need a Go Interpreter? What advantage does it provide over using a precompiled binary?
There are some circumstances where an interpreter is useful: For example, it should be possible to make better golang repls with an interpreter than with a binary. In a "scripting" scenario, you can load some golang code at runtime without needing to bring the full golang compiler toolchain along, which keeps the nice "single binary" deploys of golang. It may be possible to sandbox scripts as well (though I haven't l…
Earlier quoted context omitted.
There are some circumstances where an interpreter is useful: For example, it should be possible to make better golang repls with an interpreter than with a binary. In a "scripting" scenario, you can load some golang code at runtime without needing to bring the full golang compiler toolchain along, which keeps the nice "single binary" deploys of golang. It may be possible to sandbox scripts as well (though I haven't l…
Sandboxing is possible but only if it brings it's own standard library (I think... I'm not familiar with how go implements io at it's roots)
Earlier quoted context omitted.
For one meaning of "test", sort of, but repls are useful for far more than "do outputs match what I expect". Test writing is not very good for exploratory programming.
This tends to be more important in dynamic languages where "the outputs" are often hilariously far from what is reasonable to expect. At least that's where I find I use a REPL in Python--load in some poorly-documented 3rd party library to see what the return type of a function is (for some given inputs) and what properties are available on that object (since the "type" isn't much good given the aforementioned poor st…
Most of my experience with dynamic language programming is far from what you describe above. About the only place where I've encountered the like is with Javascript.
https://archive.org/details/wat_destroyallsoftware
I once experienced "magic" jumps in the debugger in Smalltalk, but that was because of some liberties taken with custom methods implemented in C, or because of missing_method style metaprogramming. (#doesNotUndedrstand: in Smalltalk)