Maybe it makes me a certain kind of developer to say this, but if there are like 8 idiomatic ways to do 1 extremely common thing in a language, I can’t see that as anything other than a total failure of process and design.
Probably there are author/readers who are happy to learn new grammar, vocabularies, and/or alphabets for every book they work with, but to me it just seems like an abdication of responsibility.
Are you familiar with the term “design space”, Peter? It’s entirely possible that your preferred PL hasn’t arrived at the optimal solution either. In an imperfect world, different sets of tradeoffs can be equally valid. It’s not that the ecosystem is terribly fragmented over this problem, and even Haskell practitioners have learned to navigate which idioms work in which situation (and which don’t).
YMMV, but I tend to believe that experimentation is ultimately the only way to arrive at better solutions - even if that occurs only in small increments, and even if a lot of things get re-invented in different contexts along the way. I also feel old enough to make my choices on my own.
I’m completely down with experimentation and exploring a design space. What I’m not down with is doing those things with, or in, a general-purpose, non-academic programming language. In my opinion, the authors of these languages have the responsibility to make specific decisions in all of the dimensions of the design space, so that users can build on an invariant foundation. Experimentation is better done at a different level, with a different language altogether, rather than a continuous stream of modifications to an existing one. And this is because success and failure, what works and what doesn’t, takes a long time to figure out, years at least. Users have to build several generations of artifacts on top of a language foundation to get a feel for it. Changing the foundation along with the artifacts subverts the process and largely invalidates the conclusions.
Of course I’m saying all this from a particular perspective which not everyone shares. I join organizations and use languages to deliver value. While I benefit from the results of experiments, experimentation as a process isn’t useful to me per se; the churn makes my work a lot harder.
Concretely, if I join a team whose Rust artifact spans enough time, I’ll have to learn not only the problem domain but likely many different idioms for many different things like error handling, as different techniques drifted into and out of fashion over the project’s lifetime. This overall condition sucks a lot more than whatever benefits a given experimental technique may have brought.
This post is largely describing libraries that people have written, and all of the changes to the standard library Error type it describes don’t change foundational model at all. Isn’t that “doing experimentation at a different level” than the language?
Additionally, since Error is a trait, you can use libraries that use these different error types in a normal rust program without needing to learn the new idioms that the library provides, if you want.
That seems pretty good to me, although I understand how getting it perfect on the first try would have been better :P
Maybe it makes me a certain kind of developer to say this, but if there are like 8 idiomatic ways to do 1 extremely common thing in a language, I can’t see that as anything other than a total failure of process and design.
Probably there are author/readers who are happy to learn new grammar, vocabularies, and/or alphabets for every book they work with, but to me it just seems like an abdication of responsibility.
Are you familiar with the term “design space”, Peter? It’s entirely possible that your preferred PL hasn’t arrived at the optimal solution either. In an imperfect world, different sets of tradeoffs can be equally valid. It’s not that the ecosystem is terribly fragmented over this problem, and even Haskell practitioners have learned to navigate which idioms work in which situation (and which don’t).
YMMV, but I tend to believe that experimentation is ultimately the only way to arrive at better solutions - even if that occurs only in small increments, and even if a lot of things get re-invented in different contexts along the way. I also feel old enough to make my choices on my own.
I’m completely down with experimentation and exploring a design space. What I’m not down with is doing those things with, or in, a general-purpose, non-academic programming language. In my opinion, the authors of these languages have the responsibility to make specific decisions in all of the dimensions of the design space, so that users can build on an invariant foundation. Experimentation is better done at a different level, with a different language altogether, rather than a continuous stream of modifications to an existing one. And this is because success and failure, what works and what doesn’t, takes a long time to figure out, years at least. Users have to build several generations of artifacts on top of a language foundation to get a feel for it. Changing the foundation along with the artifacts subverts the process and largely invalidates the conclusions.
Of course I’m saying all this from a particular perspective which not everyone shares. I join organizations and use languages to deliver value. While I benefit from the results of experiments, experimentation as a process isn’t useful to me per se; the churn makes my work a lot harder.
Concretely, if I join a team whose Rust artifact spans enough time, I’ll have to learn not only the problem domain but likely many different idioms for many different things like error handling, as different techniques drifted into and out of fashion over the project’s lifetime. This overall condition sucks a lot more than whatever benefits a given experimental technique may have brought.
This post is largely describing libraries that people have written, and all of the changes to the standard library Error type it describes don’t change foundational model at all. Isn’t that “doing experimentation at a different level” than the language?
Additionally, since Error is a trait, you can use libraries that use these different error types in a normal rust program without needing to learn the new idioms that the library provides, if you want.
That seems pretty good to me, although I understand how getting it perfect on the first try would have been better :P
Yeah, I may be overstating things here.
What @wesleyac said. I assume the “creating value” proposition was meant as a polemic, too.