Ivano Pagano

Hello Stephanka, I'm gonna be synthetic because I can't go to deep into the details.

I'd say that "traditional" Consistency in the DistSys is mostly done using something which looks like a State Machine.
Indeed there the idea of replacing a shared state is all but functional, and convergence of the results is based on protocols that hides the concurrent nature of communication, similar to what lock-free algorithms does.

Latest trends in research, regarding the CALM theorem and the use of "converging data-structures" like CRDT, are pushing something more akin to the FP approach in a way similar to what persistent data-structures do for single-machine programs.
Here the trick is to encode the state in a way that is independent of the order of operations, so that each version of the change history will converge.
So, from the technical point of view, the two approaches fork their path, in that the power of immutable DS is free sharing with no risks, which doesn't really translates to the DistSys world, where shared data is always an immutable snapshot of some message content.

To sum it up, FP immutability for shared state is already what DistSys are doing anyway, as you suggest. Yet the technical approach to consistency is something different and not necessarily related to FP design at the program level, even tho latest trends are adopting the FP mindset to solve long-standing issues.

First of all, many thanks to Josh Bloch for the book, which was such an inspirational and critical guide for so many software practitioners, including myself.

Now to the question.

As java, the jvm ecosystem and the programming practices has changed so much in the last decade, how much of this is reflected in the book?

Does it change focus to include new approaches (e.g. functional programming practices, streaming and reactive programming, new concurrency models), or is it focused on more technical aspects of the language and library itself (e.g. new collections, type inference, modularity)?

I ask because I'm currently working on the Scala platform, but I try to keep up with current knowledge on the jvm, and I'm curious to know how much of the book is relevant even when not working directly with the Java language.

Thanks for your time
Ivano

Well great, what a nice catch!
Thank you so much.

Ivano

Pierre-Yves Saumont wrote:
But this is not the main reason not to use them (in the book, I mean!) The main reason is that laziness is used everywhere, so it is important to learn how to work with it. By the way, laziness has been used by Java from the start. What could we do without laziness? Can you imagine programming in a language in which both branches of an if...else structure would always be evaluated? Or a language in which you could not escape from a loop until all iterations have been executed? No very useful. Java also has the lazy boolean operators (&& and ||). In Java 8, Optional has lazy methods such as orElseGet() and orElseThrow(). If orElseThrow was not lazy, the exception would always be thrown even when the Optional holds a value!

I was thinking more of library support over built-in language features.

Pierre-Yves Saumont wrote:In Java 8, lazy values are represented by the Supplier interface. In the book, laziness is used in many places. Too many to list them all!

Didn't know about Supplier, I'm going to check that for sure. Would you consider it the equivalent of a OO closure intended to make evaluation lazy?
In your experience, is there a significant cost at runtime (caused by instances generated in memory and GCed?). I heard many complain about the performance cost in scala for automatic generation of many "functional objects" used by collections and such.

Hello.
I see from the book content that there's a chapter on lazyness.

Since I consider it as one of the traditional fp features that Java doesn't natively support, how do you approach it in the book?
Is there any workaround to the language (like using closures) and how much do the solution impact the runtime performance?

Thank you

Ivano Pagano

Tim Holloway wrote:Scala got quite popular in my hometown a year or so back, but I don't recall any of the local companies actually recruiting for Scala talent.

You can add Neo4J to the systems that are written at least partially in Scala.

Just so you know, they developed the cypher engine in scala (the graph query language).

Joe Harry wrote:I have been reading about higher kinded types in Scala recently and have a simple question. What is the difference between the following?

List[A] and List[_]

My understanding is that both are the same! If so then why use an underscore?

I'll try to get there with a REPL example
scala> def foo(a: Array[_]): Unit = println(a.length) foo: (a: Array[_])Unit scala> foo (Array("1", "1", "2")) 3 scala> foo (Array((), (), ())) 3 scala> def bar(a: Array[A]): Unit = println(a.length) <console>:7: error: not found: type A def bar(a: Array[A]): Unit = println(a.length) ^ scala> def bar[A](a: Array[A]): Unit = println(a.length) bar: [A](a: Array[A])Unit scala> bar(Array("1", "1", "2")) 3

What you see here is that if you specify a type parameter A, then the type is bound to be defined in the context you're using it in. It's an explicitly named type, even though its runtime specific type is not known.
If your usage of the higher-kinded type doesn't depend on the specific type parameter, you can omit it (with the generic underscore placeholder syntax), and the compiler will happily comply.
I hope this is somewhat comprehensible.

Going to the details, the "_" wildcard, when used in this way is called an existential type and is a shorthand syntax for the more wordy (but maybe clearer) Array[T] forSome { type T}
It's like saying: 'I need a type T, but I don't care what it is, as long as it exists'.

If you're asking yourself why should I ask for existence of the type, the answer is that you can constraint the type like the following snippet

scala> def foo2(a: Array[_ <: AnyRef]): Unit = println(a.length) foo2: (a: Array[_ <: AnyRef])Unit scala> foo2(Array("1", "1", "2")) 3 scala> foo2(Array(1, 1, 2)) <console>:9: error: the result type of an implicit conversion must be more specific than AnyRef foo2(Array(1, 1, 2)) ^ <console>:9: error: the result type of an implicit conversion must be more specific than AnyRef foo2(Array(1, 1, 2)) ^ <console>:9: error: the result type of an implicit conversion must be more specific than AnyRef foo2(Array(1, 1, 2)) ^

Makes sense?


For a more detailed reference look at this post on higher-kinded types, and check the appendix links.

Also a nice reference for existential types is here on stackoverflow

Thanks Kathy for your rich answer, it's really appreciated.
I'm surprised about the dedication you put into answering in what I'd define as a satisfying and delightful approach.

I must say that after reading your recent answers to the forum I'm becoming more and more intrigued with the "product" you made, I think I won't miss the chance to have a copy.

Once again thank you for your dedication
Ivano

Hello Kathy,
I heard about the book, and I'm really curious about it.
My question is about the foundations on which it's build.

What are the most prominent working/personal experiences leading you to define your view on what matters to deliver a "best-selling product", as you describe in the book? (at least from what I understand it is about...)
Did you have a specific "aha" moment? A particular project that made you understand what's the winning factor? Some person who put you in the right perspective?

Just to know how you came about the vision presented in the book.

Thanks for being available
Ivano

I'm glad to have being so lucky, but I already possess the e-book (even if I didn't have the time to finish it yet).

I'm happy to pass the prize to another lucky fellow moose!

Enjoy
Ivano

Paul Chiusano wrote:
We usually refer to functional programming in contrast to imperative programming, not in contrast to OOP. People mean lots of different things by OO, but to the extent that it is well-defined, I think it relates more to how one organizes code, rather than whether side effects are used.

I would say that abstraction (primarily through encapsulation) is one of the main features of OOP, which couples very well with abstractions available in FP (higher order functions and function composition). It can become an effective pair.

Scala gives you lot of freedom in how you organize your code. This is a nice feature because you can experiment. But it also blurs the ways to better combine both natures of the language.
I believe it will get even better when time and experience will provide us the insights necessary to pick out the most profitable combinations.

Ivano

Great, it makes perfect sense, of course.
Thanks a lot

Ivano

Ulf Dittmer wrote:If there is a bandwidth issue then any communication will have problems. WebSockets are meant to address server-to-client communication (which generally is not possible with HTTP), and improve on latency (by not having to open a new connection for each message).

There's more to that: the throughput of a websocket connection is a concrete improvement over the HTTP protocol, whose heavier payload (headers are sent with every communication) can become burdensome if you have a frequent exchange of small bits of content.
Joe's design could be the right solution, if the pure http scenario is verified as being too slow.

I too am curious about alternative designs.
Bye, Ivano

Hello there,
A foreword:
From what I see many of the functional solutions described in the book are also available in some form in the Scalaz open-source library, which you both maintain along with many contributors.
Also it seems to me that while the book was being written, there's been an ongoing evolution of the library (e.g. scalaz streams, lenses, actors, scala machines ...) as more elegant or plain alternative solutions appeared.

Now the question is: has the book followed this ongoing evolution? Or did I make a wrong assumption?

Thanks a lot for your time and work
Ivano

Hello and thanks for being available.

Ivano