I can understand having to import the "dirty" parts of the stdlib, like I/O, or the "heavy" parts, like Unicode or timezones. But why force someone to import every single type? Most functional languages have a prelude that covers the types every non-trivial program uses: booleans, numbers, strings, collections.
> But why force someone to import every single type?
That's not importing the types, it's importing a suite of functions related to the types.
https://hexdocs.pm/gleam_stdlib/gleam/int.html - gleam/int for example. The int type is already in the language and usable, this import brings in some specific functions that are related to operations on int.
Because they selected to make a functional, not OO, language based largely on BEAM which was designed for Erlang, a functional, not OO, language. Why would you make an OO language if your goal is to make a functional language?
Dogma not appreciated. Personally don't care if a lang is functional or OO, they aren't exclusive categories. For example, several OO langs have added functional features. Don't see why this one couldn't use static methods for its immutable types. Wouldn't hurt anything, would it?
As mentioned in this thread, having to import libraries to operate on basic types is suboptimal to say the least.
One of Gleam's design goals is to not have multiple ways to do the same thing, so having to pick between using method chains or pipelines would work against that.
> having to import libraries to operate on basic types is suboptimal to say the least.
The language server will do this for you in a Gleam project.
I could imagine a method call done in a pipeline, but would have to work out the details. Maybe self/this or omit the variable name? Not sure how doable.
Folks recommended tools to alleviate Java verbosity back in the day as well. But you still have to read it—which unfortunately happens 100x more than writing.
It's not that it's wrong—at least I don't think so. It's that it's an example of a choice that is not pragmatic.
I suppose we should agree on what "pragmatic" even means, since it has become something of a cliché term in software engineering. To me, it roughly means "reflective of common and realistic use as opposed to possible or theoretical considerations".
So is having to import basic functionality a pragmatic design? I would argue no. Having to import basic functionality for integers, strings, and IO is not pragmatic in the sense that most realistic programs will use these things. As such, the vast majority of ordinary programs are burdened by extra steps that don't appear to net some other benefit.
Importing these very basic functionalities appeals to a more abstract or theoretical need for fine-grained control or minimalism. Maybe we don't want to use integers or strings in a certain code module. Maybe we want to compile Gleam to a microcontroller where the code needs to be spartan and freestanding.
These aren't pragmatic concerns in the context of the types of problems Gleam is designed to address.
To give a point of comparison, the Haskell prelude might be considered a pragmatic design choice, as can be seen from the article. It is a bundle of common or useful functionality that one expects to use in a majority of ordinary Haskell programs. One doesn't need to "import" the prelude; it's just there.
I don't personally find Gleam's design choice a bad one, and while GP was a bit flippant, I do agree that it is not an example of a pragmatic design choice.
Pragmatism is more than just giving people the quickest way to complete their task. There are other axes to consider, such as the simplicity of the compiler and the uniformity of the language experience. These contribute to the maintainability of the language itself and your own code also.
When the rule is "if you need a module, you must import it", and that applies equally to standard library modules, hex packages or your own internal modules, there are fewer mental overheads. The procedure is always the same. Incidentally, this also means that the Gleam language server can automatically add or remove import statements, which it now does [0].
Personally, I also find it pleasing that I can look at the top of a file and say "oh, this module appears to be doing some stuff with floating point math and strings". It often gives me an overview of what the module might be doing before I begin reading the detail.
What's wrong with a standard library the bits of which you want you choose to import?