Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yaegi – Yet Another Go Interpreter

blog.containo.us

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Yaegi – Yet Another Go Interpreter

#31

Post by mixmastamyk »

weberc2 wrote: post #22
kbd wrote: post #16

Earlier quoted context omitted.

> when I do, it's a regrettable experience--can't use up arrow to get previous command, can't use arrow keys to move cursor Dunno what's wrong with your readline but what you describe is default Python behavior. Try installing ipython, you'll get all that and more (such as syntax highlighting, multi-line editing, and much more).

Yeah, I'm not sure why, but this happens in VS Code's integrated terminal, which also has other readline-related issues (alt+backspace deletes to the previous space instead of deleting the previous word, for example). In any case, I still don't use the REPL except when I need to dynamically inspect some value (which isn't necessary in Go, since it's statically typed).

Windows is crippled somewhat on that front, but there are workarounds. Often easier and way more functional to just install a wrapper like ptpython, bpython, ipython, etc.

Re: Yaegi – Yet Another Go Interpreter

#32

Post by chrisseaton »

mwkaufma wrote: post #29

Bench-marking a fat native call, rather than a purely-interpreted function, is a bit bait-and-switch.

They do explain it very clearly though, and give a reason why that is what they are interested in for business purposes. Benchmark and optimise for what you're running, right? Better than a Mandelbrot?

Re: Yaegi – Yet Another Go Interpreter

#33

Post by jpittis »

wc- wrote: post #26
jpittis wrote: post #20

Earlier quoted context omitted.

To add to this, editor commands to quickly switch to your test file, auto generate test boilerplate and run the currently highlighted test are super helpful to speed up this loop.

This sounds really helpful, can you provide any links to read more about setting these helpers up?

It completely changed the way I write Go. This is editor specific though.

I use Vim for programming Go and have a few custom scripts built on top of https://github.com/fatih/vim-go.

Re: Yaegi – Yet Another Go Interpreter

#34

Post by Gonzih »

kbd wrote: post #3

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.

Ah, this famous REPL driven development. After which we are left with highly coupled codebase that has almost no tests. After doing clojure for 6+ years I forced myself at some point to disable REPL, it allows one to go fast in short term and creates way too much debt long term.

Nowadays I find repl driven approach to be not so sustainable for mid to large sizes of teams.

It is fun on small/personal projects though.

Re: Yaegi – Yet Another Go Interpreter

#36

Post by InvOfSmallC »

jpittis wrote: post #33
wc- wrote: post #26

Earlier quoted context omitted.

This sounds really helpful, can you provide any links to read more about setting these helpers up?

It completely changed the way I write Go. This is editor specific though. I use Vim for programming Go and have a few custom scripts built on top of https://github.com/fatih/vim-go .

I actually did a pair programming session with JBrains on TDD to enhance my skill. What he explained to me was exactly this. You need to test something, for example you want to test how regexp works. You start writing tests with your expectations and go on. After you are satisfied, you actually keep this in a package for reference and documentation on works the library.

Re: Yaegi – Yet Another Go Interpreter

#38

Post by yathern »

Gonzih wrote: post #34
kbd wrote: post #3

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.

Ah, this famous REPL driven development. After which we are left with highly coupled codebase that has almost no tests. After doing clojure for 6+ years I forced myself at some point to disable REPL, it allows one to go fast in short term and creates way too much debt long term. Nowadays I find repl driven approach to be not so sustainable for mid to large sizes of teams. It is fun on small/personal projects though.

Why is REPL a cause of a coupled codebase and lack of tests?

Surely those are programming practices that don't need to go hand-in-hand.

Re: Yaegi – Yet Another Go Interpreter

#39

Post by skybrian »

sreque wrote: post #21
kbd wrote: post #13

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.

I disagree with this to some extent. Unit tests are a pretty good poor-mans REPL in languages that don't have REPLs. For instance, I've seen people write fake unit tests to do things like query a database for analysis purposes; it was just the fastest way they could come up with to do the exploratory work. What makes a unit test a good poor-mans REPL in a language like java with an IDE is: * Java IDEs, especially ecl…

We are talking Go here, which has a fast compiler. The IDE integration isn't always as good as Java, though.
Post reply on HN