For anyone designing a programming language, enforce namespace to includes/imports! and if possible, don't allow top level side effects.
let foo = include "lib/foo.hurl"
foo.init()
it's much easier to reason about then, for example:
include "lib/foo.hurl" // side effects
baz(buz) // function and variable that I have no idea if they are in the standard library, or included *somewhere*
Python has this in a slightly different spot. Most pypi packages have the name and module aligned but it’s only a matter of convention, and there are some common deviations like the pyyaml package providing the yaml module.
Ah yes, Python's package manager has it wrong also. But at least Python the language is clear, so you can know "import foo" or "from bar import foo" creates a name "foo" in your file. Go has no such limitation. Imagine doing "import pyyaml" and "yaml" is the name defined...
Wait I’m so confused by this - this is the opposite of how I thought it worked? Go import creates exactly the symbol you mention in the import statement, like “import fmt” creates a symbol “fmt”?
The only example I have in mind is modules, which can have a different name from their root package.
For example you can have github.com/user/go-module as module name, and "module" as package name, so "import github.com/user/go-module" will be imported as "module.*".
There’s a linter that automatically aliases this kind of imports with their actual module name so that it’s non ambiguous when reading the import list.
Here's an example, a package bar under a totally different name:
package main
// imports 'bar', you couldn't possibly know from reading this line
import "github.com/remram44/foo20240527"
func main() {
// ??? where does this function come from ???
bar.SomeFunc()
}
Ah got it. I think there’s such a strong convention there, that it would be exceedingly rare to see in pratice. It’s probably allowed just for compat reasons at this point — but I think your point is don’t make that mistake in the first place, not that Go is filled with flagrant violations of the convention.
I'm saying that when I import something, "foo/bar" "bar/baz" etc, The way I access the exposed functions and types in that package usually corresponds to the basename. e.g. bar.* for the first example, and baz.* for the second example. Is your criticism of Go that it is technically not required for this to be the case?
I do not disagree, but I use IntelliJ for work and it shows clearly where some reference is imported from and let you navigate to it with a shortcut. VSCode does similar things with plugins and LSP, just much worse. I cannot work in VSCode because navigating code is so slow. Is this suggestion only useful when you don’t have such tools? It seems impossible to me that people can live without them, at least in a professional setting.
Let's not write software and especially programming languages which assume or depend on users having access to advanced tools that require a monthly subscription.
In case we're still in the design phase of the language, named arguments would help around that (coupled with a good IDE)... but yeah, probably i agree with how i interpret your comment.
Shouldn't be like how parent proposed imports work. Would lead to too much pain.
> I mean, it’s a language based around exceptions for flow control, I think the “easy to reason about” ship has sailed.
Sometimes I wonder if I'm exceptionally (haha) talented as I personally find the impact of exceptions on flow control pretty easy to grasp. But based on my understanding of other advanced computer language concepts, which is pretty lacking in some regards, I come to the conclusion that it can't be too hard, and people make a lot of fuss about it for no particular reason.
- you’re working in a language that doesn’t have checked exceptions, so the set of potential errors and the set of potentially error-raising calls is infinite but unknowable
- you’re working in a language that has checked exceptions, and you hate that it makes you do work, so you catch-rethrow runtime errors that recreate the first scenario
- you’re working in a language that has checked exceptions, but someone else did the second scenario so you’re in the first scenario anyway
Other programmers tend to be bad at reliably cleaning up resources such as file handles, locks etc, so I need to inspect the whole invocation tree anyways to have an understanding of what runtime implications I've summoned by invoking other people's code.
As for myself, I've lived through the hell that are checked exceptions in Java. You learn that compositionality and checked exceptions are at odds when you try to insert a remoting layer into an application that has grown without IOExceptions. Then you learn that it's actually not necessary to know the set of possible errors, just make sure that you're not a bad programmer as in my first paragraph, and everyone will be fine. This is also something that you can learn from Exceptional C++.
Yeah, I’ve never understood the complaints about exceptions either: most of the time you want the exceptions to just bubble up anyway because, in that case, you only have to think about the contracts of the functions you interact with and not about the unusual states you might be in. Return-type or return-value based error handling has always seemed to me to be significantly worse.
The unchecked exception example doesn't seem any different than using a dynamically typed language and reading return values, and exceptions seem to get significantly more hate than those.
Because even in a dynamically typed language you can generally go look at what the function returns. You can’t look at what it throws without walking the entire call stack and inspecting the source code of the runtime.
But why? I don't get it. You call something. It can break. It will break. Treat it as such wrt to resources you've allocated. You can ignore error details here.
At the highest level of your application (and at a few critical places, executors, retrying strategies etc) handle all the exceptions you know of, and implement a sane default for everything you don't know.
Not really, what’s happened is that everyone’s so scared of exceptions they only use them in extremely confined ways. These ways are relatively easy to reason about. But the full fat arbitrary goto around your call stack is avoided.
I forked Ruby to have require that didn't clobber the symbol table but then lost interest in Ruby itself because the ecosystem seems unhinged on shared global mutable state.
I enjoy Elixir but this situation is quite unfortunate, there is alias, import require and use for referencing / pulling in code external to a file in some way or another, plus the possibility of calling a function from another module directly by name without an import statement using the module name – and the most annoying part of it is that none of these give an indication of which file the other module is from, which is like 50% of the utility of an import statement for me.
Instead there is this pattern of naming modules based on the file path they are located in, which is not enforced.
Doesn't Elixir (and Erlang for that matter) specifically require a module to not be in a specific place in order to have hot reloading of modules? Though I suppose you could still have hot reloading and require a module to be in a specific place.
Not sure, could be that Elixir stuck close to Erlang's module system yeah.
But for example gleam [1] is another language on the BEAM (compiles to Erlang), that has a much nicer approach:
All imports must be declared explicitly, and the import path in your local project is based on the file structure so you always know where something is imported from [2].
This is precisely why I stopped using Nim. I was going crazy trying to remember what functions were called etc. I could do from x import nil but it felt like fighting the language.
It could be preserved if specifying the namespace used a different syntax.
Right now, if I have the `foo` module and `bar` function, I can call `arg1.bar()`, or `foo.bar(arg1)`. But if the namespace didn't also use `.`, then it wouldn't be an issue.
For sake of argument, lets choose `/` like Clojure. Then we'd get: `arg1.foo/bar()` so we can specify the namespace and uniform function call syntax is preserved.
Maybe. First, you need the module name primarily for disambiguation for compiler or possibly for readability. I wouldn't recommend requiring it for everything, eg one of the arguments against requiring naming all imported symbols explicitly is for procs that use `[ ]`.
But I think the std/strutils/split counter example isn't strong for two reasons:
1. When you disambiguate in Nim, you use just the module name, not it's full path. So it would still just be `strutils/split`.
2. If we were to introduce such a syntax, we could also introduce an `import foobarbazqux as foo` alias syntax, which is present in many languages (eg JavaScript, Clojure, etc). This would also be useful if we ever had module name collisions, which has never happened to me in Nim, but doesn't seem impossible.
