> The problem directed the choice of Go, not the other way around. I
seriously considered OCaml or a compiled Lisp as alternatives. I
concluded that in either case the semantic gap between Python and
the target language was so large that translation would be
impractical. Only Go offered me any practical hope.
I wish they expanded more on this point. Do they mean that rewriting in, say, Lisp would be longer because it wouldn't be a 'port' and more like writing a new program from scratch?
EDIT: Spoke too soon. Reading more carefully, I answered my own question.
> Python reposurgeon was 14 KLOC of dense code. At that scale, any
prudent person in a situation like this will perform as linear and
literal a translation as possible;
Yeah, that point doesn't seem to make a lot of sense. When people talk about Python and Go being similar, or filling a similar niche, I gather that this refers mostly to the short compilation time, rich standard library and easy of use. They are quite different in other ways.
Go might also be more similar in syntax than to Python than Lisp is, but the article talks about the "semantic gap" (not syntactic gap) which seems much narrower in Lisp vs. Python than in Go vs. Python.
> I did examine two automated tools for Python to Go translation, but rejected them because I judged the generated Go code would have been a maintainability disaster.
Perhaps indicating that the languages are not all that similar semantically.
I wish they expanded more on this point. Do they mean that rewriting in, say, Lisp would be longer because it wouldn't be a 'port' and more like writing a new program from scratch?
EDIT: Spoke too soon. Reading more carefully, I answered my own question.
> Python reposurgeon was 14 KLOC of dense code. At that scale, any prudent person in a situation like this will perform as linear and literal a translation as possible;