1. 5

    We switched from going round each person to going round each ticket (those in progress, in code review, blocked, QA). It cut down on time wasted justifying the day before or talking about finished work. If something major happened yesterday that needs to be raised it will naturally come up but no one’s waiting their turn trying to think of what to say to sound busy. It tends to be 5 or so minutes on the tickets, a couple on the overall progress of the sprint goals, and feels pretty useful. I don’t know if it’s capital A Agile. Edit: 4 engineers, 1-3 managers depending on who’s interested.

    1. 3

      Have you looked into opportunities to do meaningful work for free?

      My day job for a for-profit company probably has only a marginal effect on their bottom line and a negligible positive effect on the world. To me the meaning is in the tech I learn to use (really happy with this aspect!) and the less-experienced colleagues I help grow and learn.

      A friend works at the local food bank office. They have a database full of visitor and food depot location data and a lot of questions, but they don’t employ developers or even full time DBAs. I go in for a couple of hours every week or so, hear about the decisions they need to make, run some SQL and get the information they need to make those decisions. Now they know the impact of temporary closures or location changes, where they need more baby food, where they should concentrate volunteers, growth of demand, family sizes etc. The tech is boring, but in terms of impact on the community it feels significant.

      I’d like a more socially helpful job, but I’m lucky that my employer lets me shift my schedule to fit some meaningful work in as well as profitable work. Ideally I’d get both in one job but in the meantime this feels like a workable compromise. Then I sigh and read this again.

      1. 1

        What is the magic behind ${i// /_}"

        1. 3

          It’s bash parameter substitution – very useful!

        1. 1

          kinda interesting that there are now so many scala forks out there. Lots of interesting stuff happening.

          I hope it’s not too hard to share across the forks though (for example I bet the type checker could be pulled out into its own thing)

          1. 3

            Since this isn’t a fork, it will be probably next to impossible. Typelevel Scala is much closer to Lightbend Scala for such exchange to be feasible.

            1. 1

              Although given this is based on Kentucky Mule, which uses the parser from dotty, there may be some overlap between this and the next Lightbend Scala. We can hope.

              EDIT: Or maybe not: “Similarly to dotty, we are starting from a clean slate” - relatedwork.md

          1. 8

            As a total noob, on chapter 3 of the Idris book, I was surprised how much Idris feels like a tool for working programmers, rather than an academic exploration of new type theory. Lots of little touches added for developer happiness. Really enjoying it so far!

            1. 6

              I can recommend watching this talk by Edwin Brady about Idris:


              It becomes very clear many of the features like typed holes and the interactive compiler come from usability concerns.

              This also shows here: Even though this 1.0 announcement makes it clear that Idris is still a research language, it also makes clear that they want to hold platform guarantees. That gives a lot of value for further research, based on a stable foundation!

            1. 1

              How relevant is this book nowadays, 30 years later? Also, is there some epub for grabs?

              1. 2

                Don’t think an epub has been produced but you’ll find a PDF link if you remove /start.htm

                I think I only got about as far as chapter 4 or so last time I tried reading this, but chapter 2 is a wonderfully engaging and lucid explanation of the lambda calculus and Y combinator, and I’d really recommend it.

                1. 2

                  I don’t know this book, but I do recognize the author as the primary author of Haskell, so there’s probably some great food for thought in there. I’ve been reading some 30y old books by Wayne Stevens recently and found a wonderful explanation of a topic I’ve always seen explained vaguely.

                  Library Genesis has a staggering number of books, including this one, if your library is also incapable of inter-library loans.

                1. 3

                  The “Scala” example of hasUpperCase is Java. A Scala implentation would look more like this:

                  def hasUpperCase(word: String) = word.exists(Character.isUpperCase)

                  i.e. nearly identical to the clojure example.

                  In fact, after explicitly calling out Scala as a target at the beginning, most criticisms (e.g. no language-level data structures, poor concurrency, mutable-by-default, lack of external specification of behaviour using a mechanism like type classes) don’t apply to Scala, which by the author’s own reasoning mean they’re not valid criticisms of OOP. The failure to precisely define his terms makes a significant impact on what could have been a compelling argument.

                  1. 4

                    I agree.

                    I think the core essence of OO is dynamic dispatch, everything else is somewhere between nice-to-have and cruft.

                    Sadly, when functional-first/functional-only proponents argue that they can replace OO code with better FP code, dynamic dispatch is usually left out; probably because the functional alternatives are either completely horrible or can’t actually express the use cases one would use dynamic dispatch in the first place for.

                    Dynamic dispatch is incredibly powerful and dangerous, but also very useful and expressive, especially in cases where other abstractions have been exhausted.

                    Plus, a good object system can be a great module system, another thing some flagship-functional languages like Haskell are struggling with.

                    There has been this traditional thing of saying “functional is good for code in the small” and “OO is good for code in the large”, but I’d offer a slightly more nuanced view from small to large which works extremely well in good hybrid languages:

                    • OO for defining types
                    • FP to operate on them
                    • OO for extending types
                    • FP for abstracting over them
                    • OO for modularity