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

21–30 of 77 posts

Re: Yaegi – Yet Another Go Interpreter

#21

Post by sreque »

kbd wrote: post #13
skybrian wrote: post #4

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.

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.

Re: Yaegi – Yet Another Go Interpreter

#22

Post by weberc2 »

kbd wrote: post #16
weberc2 wrote: post #11

Earlier quoted context omitted.

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 e…

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

Re: Yaegi – Yet Another Go Interpreter

#23

Post by jrimbault »

weberc2 wrote: post #11
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.

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 e…

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.

Re: Yaegi – Yet Another Go Interpreter

#25

Post by mbar84 »

weberc2 wrote: post #11
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.

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 e…

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.

Re: Yaegi – Yet Another Go Interpreter

#26

Post by wc- »

jpittis wrote: post #20
marcrosoft wrote: post #18

Earlier quoted context omitted.

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

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?

Re: Yaegi – Yet Another Go Interpreter

#28

Post by [deleted] »

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…

[deleted]

Re: Yaegi – Yet Another Go Interpreter

#30

Post by stcredzero »

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…

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

Post reply on HN