Yaegi – Yet Another Go Interpreter

Re:Yaegi – Yet Another Go Interpreter by skybrian on Wednesday July 24, 2019 @12:09PM (#20516660)

You can do similar things by writing tests as you go, plus then you can keep the tests if they seem useful.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by bndw on Wednesday July 24, 2019 @04:27PM (#20519294)

In my experience, the transition from running the code to see if it works to running the tests to see if it works, is a major milestone in producing high quality software.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by kbd on Wednesday July 24, 2019 @12:53PM (#20517089)

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.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by marcrosoft on Wednesday July 24, 2019 @12:59PM (#20517164)

Tests are perfect for "do outputs match what I expect". If you don't know what you are expecting yet just to `t.Error("")`. When you are done fiddling around and want to solidify what you expect add the `if foo != expectation`.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by jpittis on Wednesday July 24, 2019 @01:03PM (#20517205)

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.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by wc- on Wednesday July 24, 2019 @01:24PM (#20517430)

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

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by jpittis on Wednesday July 24, 2019 @02:07PM (#20517926)

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.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by InvOfSmallC on Wednesday July 24, 2019 @02:45PM (#20518313)

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.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by sreque on Wednesday July 24, 2019 @01:03PM (#20517206)

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 eclipse, are amazing at fast, incremental compilation. You make one change, and then only recompile what you need to.

* Java has no relatively expensive link stage like C++, C, even C# to a lesser extent, when running tests from an IDE. Your IDE can run your unit tests and also be smart enough to only load the classes it needs to run the test.

Most dynamic languages already have a REPL, so the technique of using unit tests for exploratory work isn't necessary, but I think it's very useful for Java at least.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by stcredzero on Wednesday July 24, 2019 @01:51PM (#20517737)

Unit tests are a pretty good poor-mans REPL in languages that don't have REPLs.

Java IDEs, especially eclipse, are amazing at fast, incremental compilation. You make one change, and then only recompile what you need to.

I always found this lugubrious compared to the experience in many Smalltalks. The Java vs. Smalltalk USENET flame wars in the 90's were partly motivated by the downgrade in developer UX caused by the taking of the Smalltalk runtime model and deliberately crippling it.

Granted, Java has made amazing progress since then, as have IDEs generally. Is there a non-Smalltalk environment that lets one "code in the debugger" to the same extent as Smalltalk? I know of Clojure and the kind of experience shown with LightTable. (To elaborate, to "code in the debugger" in Smalltalk is very nimble and powerful. It's kind of like the turn-based version of LightTable but with pausing in the debugger and manual tinkering/time-travel with the context stack.)

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by sreque on Thursday July 25, 2019 @01:29PM (#20527457)

The JVM is less dynamic in its ability to reload code, but the payoff is that java code can be 10-100x faster than smalltalk code. I personally think the performance gain is worth it. Hotspot has some limited support for hot code reloading, which is a pre-requisite to being able to "code in your debugger", but it's limited enough that I don't bother with it. Alternatively, you can code in a dynamic language on the JVM such as JRuby or Clojure and have full support for "coding in the debugger". These languages are also a lot slower than Java.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by skybrian on Wednesday July 24, 2019 @03:11PM (#20518603)

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

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by sreque on Thursday July 25, 2019 @01:13PM (#20527305)

Go has a fast compiler but to my knowledge has zero support for incremental compilation. It has to recompile the entire project, transitively with all its dependencies, before you can run your code modification. I haven't code in go, but IMO this does not scale well as projects grow in size.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by stcredzero on Wednesday July 24, 2019 @04:26PM (#20519283)

I find GoLand to be quite good.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by sitkack on Wednesday July 24, 2019 @08:05PM (#20521413)

Seconded, GoLand isn't just quite good, it is phenomenal. If you aren't running it, you need to have a compelling reason.

https://www.jetbrains.com/go/

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by weberc2 on Wednesday July 24, 2019 @05:27PM (#20519929)

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 state of the docs). In Go, however, you get all the information you need from the type and godoc.org.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by stcredzero on Wednesday July 24, 2019 @06:34PM (#20520697)

This tends to be more important in dynamic languages where "the outputs" are often hilariously far from what is reasonable to expect.

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)

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by weberc2 on Wednesday July 24, 2019 @07:02PM (#20520963)

This experience is commonplace in Python. Can’t speak so much for other languages.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by mevile on Wednesday July 24, 2019 @03:53PM (#20518991)

I use the go playground for this. Only problem I have run into is lack of sane time values.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by aczerepinski on Wednesday July 24, 2019 @04:29PM (#20519318)

Me too but if I had a repl I’d probably prefer that.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by weberc2 on Wednesday July 24, 2019 @12:51PM (#20517070)

I think this is a matter of personal preference. At work my primary language is Python and I rarely use the REPL, and 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, entering tabs after the `. . .` makes it hard to figure out how many tabs to enter, etc. And of course you can't visualize the whole "program" at a glance like you can in a text editor. Not sure if Python's REPL is just subpar among repls or if I just don't understand how to leverage REPLs for my benefit, but `$EDITOR /tmp/foo.py` just works so much better for me.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by kbd on Wednesday July 24, 2019 @12:57PM (#20517141)

> 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).

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by weberc2 on Wednesday July 24, 2019 @01:06PM (#20517231)

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).

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by mixmastamyk on Wednesday July 24, 2019 @01:54PM (#20517774)

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.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by weberc2 on Wednesday July 24, 2019 @03:58PM (#20519042)

I'm using a Mac.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by mixmastamyk on Wednesday July 24, 2019 @04:05PM (#20519103)

Sounds like a broken terminal configuration. Try running python at the standard terminal and see what it does.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by weberc2 on Wednesday July 24, 2019 @04:06PM (#20519108)

Yeah, like I said, it works at a standard terminal, not in the VS Code integrated terminal.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by mbar84 on Wednesday July 24, 2019 @01:22PM (#20517408)

I have a keyboard shortcut Ctrl+Alt+i mapped to this: alacritty -e /home/mbarkhau/bin/ipy

and /home/mbarkhau/bin/ipy is this

/home/mbarkhau/miniconda3/envs/py37/bin/ipython -i -c import itertools as it; from statistics import ;import functools as ft;import operator as op;import io;import pathlib as pl;import pandas as pd;import numpy as np;import typing as typ;from math import ;import enum;import re;import sys;import os;import ujson as json;import collections;import random;import decimal;import fractions;import time;import datetime as dt;"

I must use it dozens of times a day.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by jrimbault on Wednesday July 24, 2019 @01:13PM (#20517316)

For about a year now I've used ipython as my day-to-day python REPL. I'll type a bit in ipython then save that session to a file, tidy up that file, and voila, a full script, now I can repeat that session at will.

Ipython has interactive tab completion (including for imports and locally defined symbols), syntax highlighting, (sane) auto indenting, all in the REPL. It's the foundation of jupyter notebooks.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by setr on Wednesday July 24, 2019 @12:54PM (#20517107)

Bpython is much nicer experience than the native repl, but I still really only use it to call help(), __slots__(), etc and test minor things like forgotten syntaxes; the lack of automatic reloading just makes it to irritating to work on the script itself that way

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by jpittis on Wednesday July 24, 2019 @01:00PM (#20517181)

I’ve often had similar feelings to you.

Something that blew my mind recently was using a Lisp repl which was integrated with my text editor.

I just wrote out the code I wanted to toy with in my text editor buffer, and then highlighted it and hit a key command to evaluate it at the repl without even needing to switch over to the repl window.

It would be so cool if we had great support for something similar in non Lisp languages.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by minxomat on Wednesday July 24, 2019 @12:52PM (#20517081)

I prefer a scratch file and send-to-repl. Common in e.f. F#

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by Gonzih on Wednesday July 24, 2019 @02:11PM (#20517967)

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.

[ Parent | on HN ]

Re:Yaegi – Yet Another Go Interpreter by yathern on Wednesday July 24, 2019 @02:59PM (#20518463)

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.

[ Parent | on HN ]