3 ms·

In Swift, what's wrong with writing the imperative version to start with, then switching to the monadic version as there's time to polish, or as the function lo

In Swift, what's wrong with writing the imperative version to start with, then switching to the monadic version as there's time to polish, or as the function logic evolves to a point where other styles are clearly preferable?

tptacek 8y ago
Nothing at all. His point is just that there's cognitive burden associated with making those kinds of decisions in Swift, and there isn't in Go, because you don't have those options. All things considered, he prefers Swift. But he's productive in Go as well. I've had similar experiences. I find that for some problems --- not all of them --- I can drill in quicker in Go, because the problem is all I can really think about; there isn't enough elbow room in the language to really spread out and work on the task of making things elegant. At my last company, I found that writing an emulator in Go was super straightforward, and I think Go made that task easier than a "better" language like Clojure or Swift would have. But in addition to an emulator, we also wrote a compiler, and writing a compiler and SSA optimizer in Go was fairly unpleasant. Not prohibitively so, but enough that I noticed it.
- danenania 8y ago
  I think it’s kind of akin to the premature optimization people do when they think they have ‘big data’, but really don’t. If you’re really doing heavy list processing, transforming complex data structures, etc., then you’re probably going to miss map, reduce, and friends. But for most real world problems, the code is faster to write, faster to run, and easier to understand with a few dumb loops. It’s always tempting to do things the clever way, but Go made me realize how rarely it’s actually beneficial.
  - wolf550e 8y ago
    For compilers and optimizers, people have said pattern matching support in the language is very beneficial. I bet there are other tasks where something like algebraic data types and pattern matching would make the code much simpler, and it's not really hard for the language to implement.
solidsnack9000 8y ago
The issue here can become, that there's more than one way to do that translation. Monadic operators and the underlying types are all broadly similar but not the same. It's a little like the situation in JS with promises, though with promises the convergence has been pretty rapid and one can basically ignore that the underlying implementations are different.

tptacek 8y ago

Nothing at all. His point is just that there's cognitive burden associated with making those kinds of decisions in Swift, and there isn't in Go, because you don't have those options. All things considered, he prefers Swift. But he's productive in Go as well. I've had similar experiences. I find that for some problems --- not all of them --- I can drill in quicker in Go, because the problem is all I can really think about; there isn't enough elbow room in the language to really spread out and work on the task of making things elegant. At my last company, I found that writing an emulator in Go was super straightforward, and I think Go made that task easier than a "better" language like Clojure or Swift would have. But in addition to an emulator, we also wrote a compiler, and writing a compiler and SSA optimizer in Go was fairly unpleasant. Not prohibitively so, but enough that I noticed it.

danenania 8y ago
I think it’s kind of akin to the premature optimization people do when they think they have ‘big data’, but really don’t. If you’re really doing heavy list processing, transforming complex data structures, etc., then you’re probably going to miss map, reduce, and friends. But for most real world problems, the code is faster to write, faster to run, and easier to understand with a few dumb loops. It’s always tempting to do things the clever way, but Go made me realize how rarely it’s actually beneficial.
- wolf550e 8y ago
  For compilers and optimizers, people have said pattern matching support in the language is very beneficial. I bet there are other tasks where something like algebraic data types and pattern matching would make the code much simpler, and it's not really hard for the language to implement.

solidsnack9000 8y ago

The issue here can become, that there's more than one way to do that translation. Monadic operators and the underlying types are all broadly similar but not the same. It's a little like the situation in JS with promises, though with promises the convergence has been pretty rapid and one can basically ignore that the underlying implementations are different.