131–140 of 249 posts
Earlier quoted context omitted.
Yeah, I guess some need to review the definition of abstraction.
Sometimes I feel like the OO world has redefined abstraction to only mean an interface.
https://en.wikipedia.org/wiki/Component-based_software_engin...
https://www.amazon.com/Component-Software-Object-Oriented-Pr...
You want a functional language? Use it.
You want a procedural language? Use it.
You want an OOP language? Use it.
They're all good, but not in one language.
For example, you like FP idioms, and program everything with maps.
I like for loops.
You have to fix my code one day I'm on vacation.
You think that it's ugly, and rewrite it as a map.
I get back, bug comes up, I rewrite it back to for loops.
Repeat.
Go showed how to finally end indentation wars, maybe it can show how to end style wars.
This entire piece sounds like the Blub Paradox made real. http://paulgraham.com/avg.html It's written with knocking down a very specific set of straw men in mind, but rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. One of the things that's most irritating about Go enthusiasts is the way they try to close ranks on legitimate critique and reframe their language…
But Lisp is a computer language, and computers speak whatever language you, the programmer, tell them to.
A program, especially a large one, spends far more time being read by humans than being written. Computer languages need to be readable by humans, they need the right abstractions, and the minimum of those, so that there is little to learn, little to forget, little to be confused by.
If your language lets you build abstractions only your present-day self can grok, it is less useful than a more limited one which lets you build something you and your colleagues can easily understand and modify in the weeks and months ahead.
Earlier quoted context omitted.
Go gives you the tools to handle this, but you have to do it yourself. filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for this. I find myself very productive in Go, I've written a lot of it now, but I do also find myself writing more code than I thought I would, having had some expectations set by Python and Java. Go's philosophy seems to avoid doing something which can be done incorrectly, and…
> Go gives you the tools to handle this, but you have to do it yourself. filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for this. You're missing the point—it's unlikely that you need to do anything at all; the Windows APIs handle forward slash as a path separator just fine. And on that note, for any MS employees reading now and who write READMEs and other docs for projects with publicly release…
Also, I've recently discovered Go has a lot of trouble with case sensitivity in filepaths. i.e. people tend to compare filepath strings directly instead of taking into account case sensitivity. The `path/filepath` package has a `HasPrefix` function which has been deprecated for 4 years for this exact reason[1], but in my experience it is still widely used (even in some newer semi-official Go projects like the dependency management tool[2])
[1] https://github.com/golang/go/issues/18358 [2] https://github.com/golang/dep/issues/296
> The first was assuming forward slashes for paths in tests. So, for example, if you know that a config file should be in the “juju” subfolder and called “config.yml”, then your test might check that the file’s path is folder + “/juju/config.yml” - except that on Windows it would be folder + “\juju\config.yml”. Wait what? I thought this was solved ten years ago https://en.wikipedia.org/wiki/Path_(computing)#MS-DOS.2F…
If you ask what the path of a file is on Windows, it'll give you the backslash version.
Earlier quoted context omitted.
So by that definition of magic, something like ranging over a channel is magic? It looks like a simple for each loop, just like over a slice or map, but under the covers involves locking semantics. If so, I guess I'll buy that definition of magic, I'm not sure thats any different than knowing what the language does .
In go, there are a minimal amount of primitives (like channels, slices) to learn. Once you know them, they're fairly intuitive. In C#, properties can be arbitrarily complex. You can't just know how properties "work" and then do mental shorthand on them. Every time you look at a new codebase you might have to dig through several files to find out what one line does.
In go methods can be arbitrarily complex. You can't know how they work without digging through several files to find what one line does.
Another example of magic in go would be method names. You have no idea if it is safe to change the name of a method because it could be satisfying an interface far away from the definition site (or in the case of exported methods nowhere you have access to).
We could go back and forth all day about what is and is not magic, but it still just seems like "language differences" to me. If the claim is "go does a lot less for you than other languages, so has a lot less opportunity for magic", I could probably concede that.
Earlier quoted context omitted.
> rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. The "criticisms of Go are addressed every time the language is discussed: in practice, generics are rarely missed. They would be nice to have, but their absence is outweighed by other benefits of the language. Critiques of Go tend to be principal-based: "Go doesn't have features X, Y, and Z, therefore it canno…
> I know this is heresy, but has this article really held up well over time? One immediate thought that I have - programming is now much more accessible. High-quality compilers are much easier to get, good documentation is much easier to find. Much fewer people have done nothing but work on one language, one technology stack, etc. They still exist, of course, but they're much fewer in number. This means that people a…
I don't think it does. So maybe the people picking Go have a preference for minimalism, or they pick Go despite it's lack of generics and other features, because of performance, or popularity, or tooling.
Earlier quoted context omitted.
Go gives you the tools to handle this, but you have to do it yourself. filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for this. I find myself very productive in Go, I've written a lot of it now, but I do also find myself writing more code than I thought I would, having had some expectations set by Python and Java. Go's philosophy seems to avoid doing something which can be done incorrectly, and…
> Go gives you the tools to handle this, but you have to do it yourself. filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for this. You're missing the point—it's unlikely that you need to do anything at all; the Windows APIs handle forward slash as a path separator just fine. And on that note, for any MS employees reading now and who write READMEs and other docs for projects with publicly release…
Earlier quoted context omitted.
Go gives you the tools to handle this, but you have to do it yourself. filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for this. I find myself very productive in Go, I've written a lot of it now, but I do also find myself writing more code than I thought I would, having had some expectations set by Python and Java. Go's philosophy seems to avoid doing something which can be done incorrectly, and…
> Go gives you the tools to handle this, but you have to do it yourself. filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for this. You're missing the point—it's unlikely that you need to do anything at all; the Windows APIs handle forward slash as a path separator just fine. And on that note, for any MS employees reading now and who write READMEs and other docs for projects with publicly release…
Earlier quoted context omitted.
> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.
one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the…
What can be confusing is what the meaning of `+` (or `plus` is). In some case it can be fairly obvious (e.g. concatenating sequences), while in other not so much. Operator overloading is nice, but has to be used tastefully (like every abstraction or language tool).