Yaegi – Yet Another Go Interpreter(blog.containo.us) |
Yaegi – Yet Another Go Interpreter(blog.containo.us) |
Playing around, it seems to have problems assigning int literals to int8 variables, and it seems to sometimes have problems re-assigning pointer values.
I would have expected a honest benchmark result. Which will be much worse than 6%.
Which is totally fine! an interpreter will of course be much slower. But this seems like the wrong kind of marketing by omission to me.
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).
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.
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.
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.
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.
Surely those are programming practices that don't need to go hand-in-hand.
Users can write simple scripts which change behaviour, or react to events, without needing to learn a toy-language, or even necessarily have a compiler setup.
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).
[rjp@hostname tmp]$ ls -l gosize
-rwxr-xr-x 1 rjp rjp 1126905 Jul 25 07:00 gosize
[rjp@hostname tmp]$ strip gosize
[rjp@hostname tmp]$ ls -l gosize
-rwxr-xr-x 1 rjp rjp 793704 Jul 25 07:00 gosize
[rjp@hostname tmp]$ go version
go version go1.12.7 linux/amd64xor eax, eax here we come.
* 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.
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.)
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)
I use Vim for programming Go and have a few custom scripts built on top of https://github.com/fatih/vim-go.