4 ms·

> I don't need to use my brain to do programming ... hoistStateIntoStateT :: Sem (State s ': r) a -> S.StateT s (Sem r) a hoistStateIn

> I don't need to use my brain to do programming ... hoistStateIntoStateT :: Sem (State s ': r) a -> S.StateT s (Sem r) a hoistStateIntoStateT (Sem m) = m $ \u -> case decomp u of Left x -> S.StateT $ \s -> liftSem . fmap swap . weave (s, ()) (\(s', m') -> fmap swap $ S.runStateT m' s') (Just . snd) $ hoist hoistStateIntoStateT x Right (Yo Get z _ y _) -> fmap (y . (<$ z)) $ S.get Right (Yo (Put s) z _ y _) -> fmap (y . (<$ z)) $ S.put s ... I definitely need to use my brain to read that code though.

munchbunny 7y ago
I have a similar experience with mathematics. "The differential form expressions for Maxwell's equations are incredibly simple!" Yup, they're simple after you've done all of the work to wrap your mind around differential forms in the first place. I did it at some point. It was rewarding, and it was elegant, and it was even fun, but it was anything but easy on my brain. Haskell feels a lot like that. That code snippet gave me the same feeling of having to climb a conceptual mountain to appreciate the metaphorical view at the top. I have no doubt that there is something beautiful there, but of all of the conceptual, programming related mountains I need to climb, the language abstraction one is pretty low priority, because the language I am using really is not my limiting factor. I appreciate that others who care spend a lot of time thinking about this problem, but Haskell's got a long way to go before I'm convinced that it's worth using in everyday contexts.
- quickthrower2 7y ago
  Absolutely, and I have put a decent amount of time in to learning Haskell. But I've been imperative programming since 8 yo, and as much as I love Haskell I can't be saved from finding it hard to understand. I also find it unmemorable - I could get my head around that code if I tried but 2 weeks later I will forget. I also find that code quite abstract, it looks to be solving some kind of problem that usually the language designer (if say you are in C#) would be solving. Haskell seems to be something that leaks it's mechanics into your code, where as C# keeps it for the most part nicely separated from your code, albeit with the effect of giving the programmer less power. No typeclasses etc.
- schwurb 7y ago
  Note that Haskell makes very few assumptions about the users; the quality and complexity of Haskell code varies greatly. The author of this block is dealing with an abstract topic, resulting in somewhat arcane looking code (I am sure that after some refactoring it would read nicer). It is however very possible to write really easy to understand Haskell code by ignoring its more fancy features and sticking to the most used abstractions: Monads, Applicatives and Functors. They alone are enough to write great code, no category theory, effect library, type magic or whatever is needed. Simple, real-world Haskell exists, it is just not often blogged about.
  - munchbunny 7y ago
    Fair enough, I just disagree with the premise that heavily relying on the type system actually lets you think less hard about how to implement your code. In my experience, defining the types you'll use at module boundaries is the actual hardest part. The stuff in the middle is usually straightforward until you realize you need sub-modules, at which point you're defining module boundary types again.
    - seanmcdirmid 7y ago
      A good type is like a heads up display about where you are in your implementation. Haskell types are often far away from being that, however.
tathougies 7y ago
No you dont. Thats the point. The type of the function completely determines the operation. Dont read the code. Read the type and then you know what the code has to do.
- quickthrower2 7y ago
  hoistStateIntoStateT :: Sem (State s ': r) a -> S.StateT s (Sem r) a ? Sorry even that'll get my brain CPU on 100% for a few minutes.
  - lalaithion 7y ago
    This code takes a Sem monad with a State effect in it, and turns it into a StateT monad with an inner monad of Sem and al l the other effects. I have never user Polysemy, any effects library, or type-level lists before, but I'm reasonably sure my guess is right, despite not understanding any of the code.
  - tathougies 7y ago
    Takes a Sem with a state effect and turns it into the state monad transformer over Sem with the remaining effects?
  - nilkn 7y ago
    I suspect you probably just need more experience with the base language. And I don't mean that in a bad way -- Haskell is a bit of a weird language, and it's something that you'll need to spend some time with. But indeed that's a fairly standard sort of type signature that you'll process at a glance if you've used the language a fair bit.
- md224 7y ago
  > The type of the function completely determines the operation. Really? I must be misunderstanding what you mean by "operation", or maybe this is the part of functional programming that hasn't clicked for me yet... my understanding is that the type signature tells you what kinds of things the function works with, but it doesn't tell you how the function maps the input to the output. When I hear "operation", I think of the latter. What are you referring to?
nine_k 7y ago
I take a new unfamiliar thing and I have no idea how to work with it. I take an old familiar tool and I instantly remember how to use it. What gives? When I was a boy, wise practitioners told me that being a programmer is a path of constant learning. They were right. And since then, I take learning as a natural part of the profession. I suspect it also has something to do with a high salary it commands.
- munchbunny 7y ago
  Personally, the issue isn't learning vs. not learning. The issue is where to put the energy and time that I do have for learning. For example, in my current job, the top four items in my list are all about conceptual mastery in a specific domain (cybersecurity) so that I can design better systems. For programming languages, the usual suspects are good enough. The real limitation is the intersection of human behavior interacting with a cripplingly complex technical system, and you can make multiple careers studying just that. Somewhere down closer to #15 is "learn Haskell," which comes after learning Rust/Go. Learning a "real" functional language would be much higher, but I already did that early in my career.
  - nine_k 7y ago
    Indeed, one does not always need to learn new tools when available tools suffice; the learning energy can be more effectively spent elsewhere. I only meant to notice that there's no impenetrable barrier to mastery of that, when desired. I don't think that to learn Haskell at a high level is harder than to do the same with C++. The latter just had more adoption for last 25 years, for a number of reasons. In any case, some (cursory) knowledge of Haskell improved my Java, Python, and JavaScript quite a bit, and is directly applicable to Scala in many aspects.
- EdwardDiego 7y ago
  > Programs must be written for people to read - Harold Abelson Looking at that code, it looks like it's working on a tree of some sort, but what kind? Something to do with Sem and State and Yo, I guess. At a wild guess, it's something to do with ASTs and DSLs or similar. But code that is dramatically inscrutable without metric shit tonnes of context, is bad code.
stcredzero 7y ago
I definitely need to use my brain to read that code though. Nothing new under the sun. How about APL? https://medium.com/@gordonguthrie/the-beam-needs-an-apl-y-language-6c5c998ba6d https://medium.com/@gordonguthrie/the-beam-needs-an-apl-y-la... A professor of mine used to write commercial software in APL. (Including business apps!)
- mamcx 7y ago
  I think APL fit well for business apps. Now, if you tell me some lunatic use it for make AAA games...
pxtail 7y ago
My god, this is horrible, it looks more like an ascii art than usable piece of code. Personally I don't even try to fiddle around with languages or libraries which are trying to get too fancy or too "clever" with their syntax. The reason is simple: as a developer looking at the code written a week ago by myself, using "normal" language, I'm able to somewhat recognize what's going on, after a month or two it's something produced by aliens. With code depicted above this time will shorten to what? hours? days? Additionally it will require additional effort for developer himself or anyone else to decrypt it after a while.
sameerds 7y ago
That criticism looks unfair to me because you did not quote the very next sentence which was relevant: "Gee, that’s complicated! I must be really smart to have written such a function, right? Wrong! I just have a trick!" Seems like the author deliberately picked an example that looks hard but isn't once you understand what he wants to say.

munchbunny 7y ago

I have a similar experience with mathematics. "The differential form expressions for Maxwell's equations are incredibly simple!" Yup, they're simple after you've done all of the work to wrap your mind around differential forms in the first place. I did it at some point. It was rewarding, and it was elegant, and it was even fun, but it was anything but easy on my brain. Haskell feels a lot like that. That code snippet gave me the same feeling of having to climb a conceptual mountain to appreciate the metaphorical view at the top. I have no doubt that there is something beautiful there, but of all of the conceptual, programming related mountains I need to climb, the language abstraction one is pretty low priority, because the language I am using really is not my limiting factor. I appreciate that others who care spend a lot of time thinking about this problem, but Haskell's got a long way to go before I'm convinced that it's worth using in everyday contexts.

quickthrower2 7y ago
Absolutely, and I have put a decent amount of time in to learning Haskell. But I've been imperative programming since 8 yo, and as much as I love Haskell I can't be saved from finding it hard to understand. I also find it unmemorable - I could get my head around that code if I tried but 2 weeks later I will forget. I also find that code quite abstract, it looks to be solving some kind of problem that usually the language designer (if say you are in C#) would be solving. Haskell seems to be something that leaks it's mechanics into your code, where as C# keeps it for the most part nicely separated from your code, albeit with the effect of giving the programmer less power. No typeclasses etc.
schwurb 7y ago
Note that Haskell makes very few assumptions about the users; the quality and complexity of Haskell code varies greatly. The author of this block is dealing with an abstract topic, resulting in somewhat arcane looking code (I am sure that after some refactoring it would read nicer). It is however very possible to write really easy to understand Haskell code by ignoring its more fancy features and sticking to the most used abstractions: Monads, Applicatives and Functors. They alone are enough to write great code, no category theory, effect library, type magic or whatever is needed. Simple, real-world Haskell exists, it is just not often blogged about.
- munchbunny 7y ago
  Fair enough, I just disagree with the premise that heavily relying on the type system actually lets you think less hard about how to implement your code. In my experience, defining the types you'll use at module boundaries is the actual hardest part. The stuff in the middle is usually straightforward until you realize you need sub-modules, at which point you're defining module boundary types again.
  - seanmcdirmid 7y ago
    A good type is like a heads up display about where you are in your implementation. Haskell types are often far away from being that, however.

tathougies 7y ago

No you dont. Thats the point. The type of the function completely determines the operation. Dont read the code. Read the type and then you know what the code has to do.

quickthrower2 7y ago
hoistStateIntoStateT :: Sem (State s ': r) a -> S.StateT s (Sem r) a ? Sorry even that'll get my brain CPU on 100% for a few minutes.
- lalaithion 7y ago
  This code takes a Sem monad with a State effect in it, and turns it into a StateT monad with an inner monad of Sem and al l the other effects. I have never user Polysemy, any effects library, or type-level lists before, but I'm reasonably sure my guess is right, despite not understanding any of the code.
- tathougies 7y ago
  Takes a Sem with a state effect and turns it into the state monad transformer over Sem with the remaining effects?
- nilkn 7y ago
  I suspect you probably just need more experience with the base language. And I don't mean that in a bad way -- Haskell is a bit of a weird language, and it's something that you'll need to spend some time with. But indeed that's a fairly standard sort of type signature that you'll process at a glance if you've used the language a fair bit.
md224 7y ago
> The type of the function completely determines the operation. Really? I must be misunderstanding what you mean by "operation", or maybe this is the part of functional programming that hasn't clicked for me yet... my understanding is that the type signature tells you what kinds of things the function works with, but it doesn't tell you how the function maps the input to the output. When I hear "operation", I think of the latter. What are you referring to?

nine_k 7y ago

I take a new unfamiliar thing and I have no idea how to work with it. I take an old familiar tool and I instantly remember how to use it. What gives? When I was a boy, wise practitioners told me that being a programmer is a path of constant learning. They were right. And since then, I take learning as a natural part of the profession. I suspect it also has something to do with a high salary it commands.

munchbunny 7y ago
Personally, the issue isn't learning vs. not learning. The issue is where to put the energy and time that I do have for learning. For example, in my current job, the top four items in my list are all about conceptual mastery in a specific domain (cybersecurity) so that I can design better systems. For programming languages, the usual suspects are good enough. The real limitation is the intersection of human behavior interacting with a cripplingly complex technical system, and you can make multiple careers studying just that. Somewhere down closer to #15 is "learn Haskell," which comes after learning Rust/Go. Learning a "real" functional language would be much higher, but I already did that early in my career.
- nine_k 7y ago
  Indeed, one does not always need to learn new tools when available tools suffice; the learning energy can be more effectively spent elsewhere. I only meant to notice that there's no impenetrable barrier to mastery of that, when desired. I don't think that to learn Haskell at a high level is harder than to do the same with C++. The latter just had more adoption for last 25 years, for a number of reasons. In any case, some (cursory) knowledge of Haskell improved my Java, Python, and JavaScript quite a bit, and is directly applicable to Scala in many aspects.
EdwardDiego 7y ago
> Programs must be written for people to read - Harold Abelson Looking at that code, it looks like it's working on a tree of some sort, but what kind? Something to do with Sem and State and Yo, I guess. At a wild guess, it's something to do with ASTs and DSLs or similar. But code that is dramatically inscrutable without metric shit tonnes of context, is bad code.

stcredzero 7y ago

I definitely need to use my brain to read that code though. Nothing new under the sun. How about APL? https://medium.com/@gordonguthrie/the-beam-needs-an-apl-y-language-6c5c998ba6d https://medium.com/@gordonguthrie/the-beam-needs-an-apl-y-la... A professor of mine used to write commercial software in APL. (Including business apps!)

mamcx 7y ago
I think APL fit well for business apps. Now, if you tell me some lunatic use it for make AAA games...

pxtail 7y ago

My god, this is horrible, it looks more like an ascii art than usable piece of code. Personally I don't even try to fiddle around with languages or libraries which are trying to get too fancy or too "clever" with their syntax. The reason is simple: as a developer looking at the code written a week ago by myself, using "normal" language, I'm able to somewhat recognize what's going on, after a month or two it's something produced by aliens. With code depicted above this time will shorten to what? hours? days? Additionally it will require additional effort for developer himself or anyone else to decrypt it after a while.

sameerds 7y ago

That criticism looks unfair to me because you did not quote the very next sentence which was relevant: "Gee, that’s complicated! I must be really smart to have written such a function, right? Wrong! I just have a trick!" Seems like the author deliberately picked an example that looks hard but isn't once you understand what he wants to say.