41–50 of 99 posts
The translation assistant you write is actually very interesting. Heavily rule based but surprising to see it actually helps at all.
But the scale of the project itself seems still pretty limited, reimplementation could still be an option.
Overall good read and interesting approach
Go is probably more verbose because it’s missing List comprehensions, for example. It needs map, filter, reduce to reduce line count. Swift, while probably not as performant as Go, makes writing in a more Pythonic style. [1,2,3,4,5,6,7,8,9].filter {$0 % 2 == 0}.map {$0 * 2}.reduce(0, +) ["550", "a", "6", "b", "42", "99", "100"].compactMap{Int($0)}.filter {$0 https://github.com/melling/SwiftCookBook/blob/master/functi…
If it was too slow in Python and now moving to Go. Could there a time when there is a need to move to Rust/C/C++ for even faster performance? Go seems an odd choice based on performance consideration alone.
Especially with node.js/TypeScript one can reach similar performance to Go with arguably much nicer programming language to work with.
Go is probably more verbose because it’s missing List comprehensions, for example. It needs map, filter, reduce to reduce line count. Swift, while probably not as performant as Go, makes writing in a more Pythonic style. [1,2,3,4,5,6,7,8,9].filter {$0 % 2 == 0}.map {$0 * 2}.reduce(0, +) ["550", "a", "6", "b", "42", "99", "100"].compactMap{Int($0)}.filter {$0 https://github.com/melling/SwiftCookBook/blob/master/functi…
Note that this is the case because Go lacks generics, so it's not a quick or easy fix
The original Python code using exceptions was:
sink = transform3(transform2(transform1(source)))
sink = transform3(transform2(transform1(source)?)?)?Adding lookbehinds to the regexp library is a terrible idea. > The regexp implementation provided by this package is guaranteed to run in time linear in the size of the input. Python's is exponential, because it inherits all the non-regular "regular" expression mess (such as lookbehind and backrefs) from perl. One would assume esr would have marinated in unix culture for long enough to be aware of this.
Some projects need performant regexes, and some honestly just don't. I agree that keeping the base regex library linear is admirable, but it's be nice if they offered a well-marked thing like regex.slow_and_perl_like in the stdlib
Also, Perl-style (ir-)regular expressions, despite their popularity, are not a worthwhile abstraction IMO and thus should not be enshrined in the standard library of programming languages, even if you want them in your library eco-system for end-user facing API compatibility.
There would probably be a much longer list of issues if ESR had converted to Rust instead, but the syntax for error returns is quite interesting. Rust and Go both opt not to have exceptions, instead they use error return values. The original Python code using exceptions was: sink = transform3(transform2(transform1(source))) Making that use error return values looks quite verbose in Go, but Rust has syntax specificall…
i.e transform1 returns (result, error) and transform2 accepts (result, error) and short-circuits if err is not nil.
It allows the expressive and succinct description of a transformation list but with a bunch of messiness hidden.
Here's another experience report: I ported a small 1 KLOC PHP project to Go this week (in some spare time between large C++ compile times). The primary goal was to reduce the number of supported languages we use. The port happened in the mechanical line-by-line way, copying each PHP file to a *.go and fixing all the syntax. The project was small enough that automation wasn't interesting. I agree with the "1/3 time sp…
func f(x int, y int, c string)
type funcOptions struct {
x, y int
c string
}
func f(o funcOptions) {}
f(funcOptions{x:3, y:-1, c: "hello"})