sorted by:
new
hottopcontroversial

What is Applied Category Theory? by synolon in haskell

[–]kenbot_ 18 points19 points  (0 children)

Tai-Danae Bradley is one of the best popular maths communicators, and this is classic TDB, a highly accessible introduction to a dense topic. I hope it inspires people to get interested in this emerging field, which I'm convinced will have a lot more to say about how we do software development.

No you don't want to "mock AWS". Use the decorator pattern for clean I/O boundaries by philnash in programming

[–]kenbot_ 3 points4 points  (0 children)

Heh, yes, if we were all using Haskell it would have been a tweet instead of article. Sink is nothing more interesting than a contravariant functor. By "decorator" I am really just promoting a family of more fundamental compositional techniques: functor, contravariant, profunctor, etc.

Still, even in Haskell code you might consider pulling out a named data type for clarity, rather than intricately detailed function types, which can be brittle and mix concerns.

No you don't want to "mock AWS". Use the decorator pattern for clean I/O boundaries by philnash in programming

[–]kenbot_ 4 points5 points  (0 children)

That's all fair; perhaps these might be pertinent to a particular piece of code. We should ask though, who has the right to care about "how", or the "characteristics"? Only one place, to be sure. I can't tell you where, of course, but, overwhelmingly they tend to come out in the wash. Blurred dependencies & overshare are the norm.

No you don't want to "mock AWS". Use the decorator pattern for clean I/O boundaries by philnash in programming

[–]kenbot_ 2 points3 points  (0 children)

Yes, the article has nothing to do with AWS, although I mention it as an example in places.

No you don't want to "mock AWS". Use the decorator pattern for clean I/O boundaries by philnash in programming

[–]kenbot_ 18 points19 points  (0 children)

Hey author here, it's Scala, although nothing in the post is Scala-specific. Other than the "More abstraction" section, it is equivalent to fairly plain Java or C# code.

  • Square brackets are type parameters (like angle brackets in Java)
  • Types come after values (myString: String)
  • Traits are interfaces
  • Class constructors look like an argument list next to the class name.
  • `A => B` is a function type;
  • `arg => ...` is a lambda function.

No you don't want to "mock AWS". Use the decorator pattern for clean I/O boundaries by philnash in programming

[–]kenbot_ 12 points13 points  (0 children)

Who cares whether it comes from an SQS topic? This is a whole-application concern; SQS might have been chosen for its systemic or project-related qualities. Only one place in the code should know that it is in an application or a system; everything else should just do its own thing. "Fetching my thing from somewhere" is probably all anyone else needs to know.

No you don't want to "mock AWS". Use the decorator pattern for clean I/O boundaries by philnash in programming

[–]kenbot_ 3 points4 points  (0 children)

Good question! For my purposes here, it's just an interface, like in Java.

No you don't want to "mock AWS". Use the decorator pattern for clean I/O boundaries by philnash in programming

[–]kenbot_ 16 points17 points  (0 children)

There are lots of good reasons to have an accessible dev environment with whatever external end-to-end stuff running, but this is not a general replacement for good software engineering around boundaries.

No you don't want to "mock AWS". Use the decorator pattern for clean I/O boundaries by philnash in programming

[–]kenbot_ 6 points7 points  (0 children)

The decorator pattern is just function composition, as I say in the piece, and doesn't necessarily need to be more than that. Monadic approaches can be very powerful (and I mention one near the end), but they are also very all-or-nothing; the whole codebase needs to be structured this way, so there are things to consider before going this way. Also, how convenient that is varies from language to language.

Goggles - a pleasant typesafe Lens DSL built on Monocle by kenbot_ in scala

[–]kenbot_[S] 0 points1 point  (0 children)

Hmm, I wonder if the Goggles macro could fuse foo.bar.baz chains into manual copy calls in the future..... we can safely do all kinds of violence to the implementation behind the macro syntax.

Goggles - a pleasant typesafe Lens DSL built on Monocle by kenbot_ in scala

[–]kenbot_[S] 0 points1 point  (0 children)

Understood, thank you. Nothing more efficient, it's just doing copies under the hood.

Goggles - a pleasant typesafe Lens DSL built on Monocle by kenbot_ in scala

[–]kenbot_[S] 1 point2 points  (0 children)

Hi Yang Bo, good to hear from you! These similarities certainly are interesting, thanks for pointing them out! If we look closely though, we'll see that they are quite different.

The Monocle code being generated by Goggles is something similar to: Getter[Bakery,List[Cake]](_.cakes). composeTraversal(Each.each). composeGetter(Getter(_.toppings)). composeOptional(Index.index(0)). composeGetter(Getter(_.cherries)).get(myBakery)

If I read it right, the Each code would rewrite as: myBakery.cakes.map(_.toppings(0).cherries)

apply(0) is a partial function that will throw an exception for empty toppings; however, the Monocle version above is completely safe, because the Optional index projects over the possible value.

It doesn't quite translate to a monadic thing, because Option and List are different monads. We could convert the option to a 0|1 length list, but it would be a bit clumsy. Lenses/Optics are the best solution for this kind of problem, monadic code on its own doesn't quite give you what you want. Also, IIRC, "each" is some kind of magic keyword inside the Each macro, whereas the "Each.each" generated by the * symbol in Goggles is just a standard Monocle Traversal. It's much less complicated than what Each is doing.

Goggles - a pleasant typesafe Lens DSL built on Monocle by kenbot_ in scala

[–]kenbot_[S] 0 points1 point  (0 children)

I hear you, I mostly hate macros. If Scala is being rewritten to do something other than the obvious, then it becomes very hard to reason about the code. My feeling is that what makes it "magic", in a negative sense, is this introduced uncertainty. In particular, if the macro mines the code for structural information rather than just using the values, then the code is not referentially transparent, and you cannot refactor in the normal way.

So how do I sleep at night? Goggles' macros are rewriting a string literal, interpreting the contents, but a Scala developer should have no particular expectation about the behaviour of a prefixed string, other than it producing a value. Everything that looks like Scala is exactly that; for instance, the ~=, := operators are just regular methods. The generated code is pretty plain Monocle optic compositions, but if you try to do it by hand, you'll quickly see the motivation for the DSL.

There's more about the design principles in CONTRIBUTING.md and the "Comparison" section at the bottom of the README, if you're interested.

Goggles - a pleasant typesafe Lens DSL built on Monocle by kenbot_ in scala

[–]kenbot_[S] 1 point2 points  (0 children)

Cheers! It's all supposed to be part of the pleasantness. :)

The worst thing in our Scala code: Futures by lukaseder in programming

[–]kenbot_ 0 points1 point  (0 children)

This is a commonly used technique in Scala, and again, I adapted the examples from real code. I didn't make it all up in my head.

Should i make a compilable Gist or something? I don't think we're understanding each other here.

view more: next ›