Sean Corfield

Brent Laster wrote:the first-hand perspective, personal experience, advice about what doesn't work or doesn't work as expected, and ordered presentation so people can jump in at whatever level of knowledge they have about actions are things I personally think are better covered in the book.

Thanks. I suspect I can improve my projects' GH Actions

Hi Brent,

In the ToC for your book, there's a chapter about migrating to GH Actions. I see several CI systems mentioned but not BitBucket Pipelines (Atlassian).

What advice would you give to someone using BitBucket Pipelines in terms of a possible migration to GH Actions?

Hi Brent,

I've been using GitHub Actions for a while on several of my OSS projects. I've used GitHub's own documentation for that so far.

What will I learn from your book that I won't learn from the documentation? (or, perhaps, won't learn easily from the docs)

Ben Weidig wrote:Congratulations to the four winners    I hope you like the book!

I am really looking forward to reading it! Very excited about winning a copy!

Junilu Lacar wrote:Another analogy is an English-speaking person trying to learn French or Spanish

That's a fair point.

Just like The Pragmatic Programmer recommends, I make a point to learn a lot of programming languages beyond what I use for work, and I suspect Lisp family languages are easier to read for folks who know a number of non-mainstream languages (I've used over a dozen languages in production, over the years, and learned over a dozen extra "for fun" -- on top of the dozen or so I learned while I was at university).

Lisp looks pretty "normal" compared to stuff like APL, Forth, and Smalltalk

Thanks for your thorough and well-considered answers! I think your book is going to be a great read.

Ben Weidig wrote:Without knowing the syntax, non-Clojure devs will immediately be lost

I hear this a lot but I must confess I don't really understand why. After all f(1, 2, 3) just becomes (f 1 2 3) and obj.method("a", "b", "c") just becomes (method obj "a" "b" "c") so it's not really that different

Campbell Ritchie wrote:
I presume you are familiar with the techniques for creating immutable datatypes, and know that the process became much easier in Java16 (I think) when records were introduced.

Yes, although Java 16 appeared long after I switched to Clojure (records were in preview in Java 14 but that was also still several years after I'd switched to Clojure)

Records definitely help but you still have to be careful about mutable instance data escaping via the implicit getters, requiring you to either override the constructor or the getter to provide an immutable copy, and there are some things that are still fairly verbose (compared to more FP-focused languages) such as producing a new record instance from an existing instance where only one or two fields are different: FP-focused languages usually have fully immutable data structures (deep immutability) and use some form of persistent data structure implementation to make operations that produce "modified" structures quite cheap and efficient.

It would be nice to have a more compact syntax for "construct a new Point record from myPoint with x = 0" (yes, you can do new Point(0, myPoint.y()) but that doesn't scale well for a record with, say, ten fields and you only want to vary one or two of them).

You touched on this very briefly in one answer here but I'd like to dig a bit deeper, if you don't mind...

My "daily driver" for the past decade has been Clojure which is immutable by default. Several FP languages I've used over the decades have also been immutable by default but more mainstream languages that are adopting FP features are all mutable by default with some, usually limited, support for immutability.

How important do you feel immutability is in functional style code?

How do you balance that immutability with Java's mutable by default nature.

What advice do you have for trying to work extensively with immutability in Java?

Thanks!

Ben Weidig wrote:
need to integrate it 12 years after the language's inception.

This made me curious about the timeline...

Java 1.0 came out in early 1996

Java 8 added lambdas and came out in the spring of 2014

So that's about 18 years -- which makes what the language's designers did even more amazing, in my opinion. Java is 27 years old and has had 20 major releases so far (with another due in three months) and yet it has retained backward compatibility in nearly all cases, while still changing in some fairly radical ways.

Language design and stewardship are hard! Brian Goetz (who was the spec lead for lambda expressions) gave a great talk about this, the year Java 8 was released, at Clojure/conj (of all places!). Definitely worth watching: https://www.youtube.com/watch?v=2y5Pv4yN0b0

There's a lot to like about Scala -- and it is a very impressive language in terms of design and concepts -- but there are also a number of downsides.

We used it at work for close to 18 months before giving up on it. We started with 2.7 and went through the 2.8 migration which was absolutely awful: every single milestone build we tested against was binary-incompatible with previous builds and you had to update the entire toolchain to get it all to work together. Apparently, the 2.9 migration wasn't quite as bad but we just couldn't face it...

In addition, the compiler was very slow (and I believe it still is pretty slow?), and the error messages are generally terrible -- especially around the standard library with all of the implicit conversion stuff in collection operations.

The language itself is pretty complex, and some developers struggle with some concepts, so it's hard to figure out an effective "style guide" for what features to use and how to write idiomatic code -- and there's a bit of a schism in the Scala community itself that reflects that: you get the "better Java" crowd, using Scala primarily as a more concise and more expression "Java", and then you get the "pure FP" / Haskell / ScalaZ crowd who mostly eschew the OO side of the language and often produce "beautiful" code that the average Java developer is going to struggle to comprehend. In addition, the evolution of the language has followed a fairly academic arc (understandable, given how/where it was created and maintained) which I feel generates a lot of friction with mainstream Scala users at times.

I loved attending Scala user groups and conferences for a couple of years -- I'm in the San Francisco Bay Area so there was an incredibly active community here for a while! -- and I'm a big fan of FP so that aspect of the language really appealed to me. Ultimately, we switched to Clojure at work (in 2011) and have been very happy with that decision.

As a big fan of FP, I'm very pleased to see several authors encouraging that style in Java, and I think the overall direction of the Java language has been very encouraging (from Java 8 onward -- I had become very disillusioned with Java by the time Java 5 appeared but since 8 came out it has slowly warmed my heart again after I'd been using Java since 1997!)

"A monad is just a monoid in the category of endofunctors, what's the problem?"

I don't know where that quote came from but you can get a T-shirt with it on and it sort of sums up the whole "what is a monad?" thing.

Over the years, I have seen so many blog posts that try to explain monads by analogy and they all pretty much fail. A monad is like a burrito. A monad is like a writing desk. There was an r/ProgrammerHumor post that said a monad is like a colostomy bag but it has been deleted.

I'm a mathematician by background and studied category theory but I would be hard-pressed to explain a monad in any useful terms that most programmers could understand. I think Evan Czaplicki did the right thing when he created Elm and pretty much forbade the community from using the M-word because he wanted Elm to be welcoming to JavaScript programmers.

Most of us use monadic constructs in our daily programming lives and just don't realize it. Written code around a data structure that can hold an error or a success value? Written code around an optional value? Written a for-comprehension? (many languages have that built-in, including Scala) Congratulations, you've written monadic code.

Languages that enshrine the monad -- or rather the family of monads -- in code, either in the language itself or in a library, are just giving names to an abstraction that makes writing these constructs a bit easier and a bit more generic.

Michał Płachta wrote:I think it's all a matter of preference

I agree and, yes, I also see FP techniques as universal, regardless of language and regardless of static vs dynamic typing!

Also, I love the other two books you mentioned.

Oh, cool. Yes, I've enjoyed them both immensely (I know both authors personally so it's been interesting to watch them writing new material in this ever-more-popular field).

Thank you, Michał!

It's nice to see another book focusing on making FP techniques more palatable to a wider audience! Manning certainly seems to have been a tear with this topic lately, which is a good thing as far as I'm concerned.

Your book focuses on statically typed FP techniques -- comparing Java and Scala -- but we've also recently had Grokking Simplicity, which aims to teach FP using JavaScript as an example language and therefore dynamically typed, and Data Oriented Programming, which uses Java as the example language but focuses on "pure data" using generic data structures and mostly avoiding the static type system.

Could you comment on what you see as the pros and cons of static typing in the context of FP, as a way to compare and contrast your book's approach to those other two?

In particular, how do you feel about Alan Perlis' quote "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." which many people feel argues more for generic functions on generic data structures? Alan Perlis -- Epigrams in Programming

Every language has different syntax and it's a good thing to learn multiple languages, especially multiple languages that are very different to each other.

Syntax is also pretty much "surface" -- it's sometimes alien to start with but you soon get used to it and then you don't think about it.

Semantics and idioms are far harder to learn and get used to.

My opinion is that you should set aside your concerns about Kotlin's syntax and push on with learning it -- it has a lot of interesting ideas that are not present in Java and it is a much more expressive language.

In general, I'd recommend reading The Pragmatic Programmer and trying to follow its suggestion to learn a new programming language "every year" (realistically, I think every two years is more practical). Learning several languages will expose you to different concepts, idioms, and ways to solve problems -- which will in turn make you a better programmer in your "home" language.

I started doing Java in 1997, after years of C++ and C. I had done COBOL and various assembly languages before that. Since Java, I've done Groovy, Scala, and now I mostly do Clojure. Along the way, over the last decade, I've learned Kotlin (I like it very much), Rust (very interesting concepts), Go (I did not like it at all), Elm (very interesting but perhaps not very practical). I've also made repeated attempts to learn Haskell over the past thirty years (I've done better with Standard ML). In the previous decade, I learned Ruby, Python, PHP, Perl, ColdFusion, and several other languages. Broaden your world!

Are there specific aspects of Kotlin that do not resonate with you? Is it about syntax, or about some of the idioms?