61–70 of 110 posts
> In general, Go strongly encourages being explicit about errors. That's completely incorrect: it's trivial (and common) to just ignore errors in Go: ok, _ := Foo() Checked exceptions don't let you get away with this kind of sloppy programming.
Here's a solution to the diamond dependency problem: Imports can only be done for a specific lexical scope. Also, imports must specify a particular version. Lastly, calls to a package go to a specific version of the package, and types are defined in a specific version. (This is why all imports must be done for a specific lexical scope.) The same scheme could be used to resolve diamond dependencies in multiple inherit…
I'm certain I'm biased, but in my experience it's been the most robust way to handle versioning that I've dealt with.
Earlier quoted context omitted.
I really am not a fan of the lack of versioning, even with that explanation. Of course diamond dependencies are a problem. But they haven't actually fixed that problem; they've just declared a method for picking one of the two dependencies that is ill defined ("whichever one you happen to have pulled in first"). At least with versioning I get told that there's an incompatibility in the expectations between two librar…
I have never really thought about this problem before, but would it not be possible to: 1. Treat each version of a package as a separate package. If there are two versions required, they are both included. 2. At compile time transform package names to include the desired version number. I may be completely misunderstanding or over-simplifying this problem.
Earlier quoted context omitted.
I have never really thought about this problem before, but would it not be possible to: 1. Treat each version of a package as a separate package. If there are two versions required, they are both included. 2. At compile time transform package names to include the desired version number. I may be completely misunderstanding or over-simplifying this problem.
For some things, yes. But there are a lot of potentially tricksy issues in doing that. Imagine a queueing library, for instance. You push something onto a queue created with library A, and then you want to read from library B (A and B are different version of the same library). Just about anything could happen (depending on how the library/language are implemented). You might get an error due to library B reading a d…
Here's a solution to the diamond dependency problem: Imports can only be done for a specific lexical scope. Also, imports must specify a particular version. Lastly, calls to a package go to a specific version of the package, and types are defined in a specific version. (This is why all imports must be done for a specific lexical scope.) The same scheme could be used to resolve diamond dependencies in multiple inherit…
That's essentially the solution Rust and Cargo adopt. It occasionally causes strange errors like "expected Foo, found Foo" (where the first Foo was, say, Foo version 1.1 and the second was Foo version 1.2), but the compiler now detects this situation and tries to explain what's going on. I'm certain I'm biased, but in my experience it's been the most robust way to handle versioning that I've dealt with.
Imports naming specific versions would also allow better integration of code/build into a version control system. Actually, the entire OS should be built with version control in mind from the ground up.
Kernighan's response to the C question was rather odd -- where is this myth that C is only used in embedded systems and drivers coming from? The Linux kernel is still written in C. Ben Klemens, author of 21st Century C, leads the statistical computing group for the research arm of the U.S. Census Bureau. He models complex systems and computations in C. The entire Python scientific computing stack is resting on C. A h…
Earlier quoted context omitted.
Everyone seems to overlook this, but Go has had LiteIDE for a very long time and it keeps getting better.
I thought the same. I use it every day and its great. I dont understand why it doesn't get more traction.
For better or worse, a sizable proportion of developers choose IDEs on the basis of looks.
Earlier quoted context omitted.
> Checked exceptions don't let you get away with this kind of sloppy programming. They sure do. Just write your Java code without a try/catch block anywhere, or just have your catch do absolutely nothing. You can do it, trust me. Exceptions don't stop programmers from doing anything.
Just write your Java code without a try/catch block anywhere The point of checked exceptions is that you can’t do that. It is a compile-time error to not either catch the exception or explicitly indicate that you will propagate it. Unfortunately, at least in Java, that style proved too onerous for a lot of programmers and motivated the catch-all, do-nothing wrapper idiom that is completely unhelpful as far as safety…
> The point of checked exceptions is that you can’t do that.
Sure you can. You just have to write "throws Exception" after all your function signatures.
Earlier quoted context omitted.
Just write your Java code without a try/catch block anywhere The point of checked exceptions is that you can’t do that. It is a compile-time error to not either catch the exception or explicitly indicate that you will propagate it. Unfortunately, at least in Java, that style proved too onerous for a lot of programmers and motivated the catch-all, do-nothing wrapper idiom that is completely unhelpful as far as safety…
> > Just write your Java code without a try/catch block anywhere > The point of checked exceptions is that you can’t do that. Sure you can. You just have to write "throws Exception" after all your function signatures.
Earlier quoted context omitted.
The fix for Google is to check in all third party libraries locally, so you get the same version as everyone else in the company until someone decides to check in an upgraded version. It works fine and anyone else is free to do the same. But that requires a monorepo that scales and people to test and check in the upgrades, so it doesn't work well for open source development, which is why people are working on alterna…
Right, but you could do that with version numbers, too. The difference between updating from "whatever version was pulled in at the time we first set up the repo with this library" and "current" is no different than updating from "version X" to "version Y", except that you don't know what the differences are, and there's no way to determine that it would be easier (and possible) to update to version X.1, since that i…
But this can all be done using a separate system. The build system itself doesn't need to know anything about versions. If you look at Bazel, it doesn't let you specify versions for target deps. Only the developer actually upgrading a third-party library needs to deal with open source version numbers, and everyone else can build on their work.