Win a copy of Rust Web Development this week in the Other Languages forum!

T Weston

author
+ Follow
since Apr 19, 2006
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
6
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by T Weston

Hi,

It has some minor updates but it's essentially the same book. I had updated the Leanpub version with the story of how it was purchased by Apress but it's not worth buying the Apress version if you have a recent red book version.

Thanks
3 years ago
Scala offers some more advanced language features than Java and offers better support for functional programming, so "why another one?" is, I imagine because Odersky and others felt they could improve on the current language landscape. It's another question if the developer community agree but it's evident that Java (and the software development industry as a whole) has been heavily influenced by Scala (the latest example being the introduction of val/vars in Java and the trending appetite for FP).

A fair few of the Scala founders worked on Java back in the day, so it's not a far stretch to imagine they learned a lot from the process and wanted to have another go with fewer constraints... see what Odersky has to say on the topic: https://www.artima.com/scalazine/articles/origins_of_scala.html
3 years ago

There are a lot of projects related to Scala itself which are very impressive and interesting - things like cats, scalaz, magnolia, hydra (a distributed compiler), shapeless and so on. These build on the language and offer tools for you to use when building apps but they're not really frameworks. In terms of the "killer" framework - I don't really think any stand out. As mentioned, there's often a implied application of Scala to "big data" and blockchain problems and plenty of frameworks to help, but it's not like MatLAB or R where there's specific domains or problems that are well suited to solve. Scala is a general purpose language and so can solve most problems.

I tend to think a framework or library shouldn't push you towards a language - rather any language should be able to solve the majority of problems; it's just how easy or difficult they make the job!
3 years ago
I'd caution about automatic conversion of Java to Scala in production projects. They do a literal conversion (and sometimes are unable to covert) and so will generally produce non-idiomatic Scala. A simple example is creating POJO objects - Scala will favor "case classes" and any Java conversion won't have the context to convert. They will also (generally) not convert Java collections to Scala so you will miss out of Scala library advantages (and some syntax sugar like for comprehensions).

If you use automatic converters, you will only learn Scala syntax (and not all of it) and not Scala idioms - which is arguably the best thing about Scala.

I'm bias, but absolutely a book will be worth your time!
3 years ago
I'd just chip in and say that although there is interop between Scala and Java, it's generally not very straight forward. Specifically, if you convert from a Java collection to Scala or the other way round, there will be a lot of noise/boilerplate and if you don't bother, you won't be taking advantage of the language features (for example, you'll end up calling flatmap and not flatMap when using Java collections in Scala and won't be able to use for-comprehension).
3 years ago
There are certainly some more advanced langauge features in Scala. If you can levarage these, they can make your life as a developer easier but honestly, language choice isn't my biggest problem. So anything you go to management with is at best subjective.

There are syntax features which you'll love and miss going back to Java (pattern matching and for-comprehencions for example) and you may find Scala's library APIs for intuative (the collections are easier to work with to map over etc and the API for Option/Optional is just better and the lambda syntax is more concise and their usage more flexible) but... if you're used to and productive with Java's stream API and have gotten used to Optional's API, there's not a complelling argument either way.

I've certainly worked with teams that felt Scala was more modern and would attract great talent, so the switch was motivated by recruitment.

If you're interested, I have a real world project that was written in Java 8 and ported to Scala. Both versions are available on branches at https://github.com/tobyweston/radiate for direct comparison but it's not really a question of which has less code IMO, the Scala version affords a more pronouced move towards FP. It may (or may not) have less code but its certainly different! For example, using type-classes in Scala (which isn't possible in Java) makes for an interesting read.
3 years ago
Possibly... I'm not sure what the specifics are there.

Some general FP abstractions (of the top of my head) are: monoids, monads (a specific monads like the IO/Free/Task monads), functors, applicatives, some category theory stuff, type classes, higher order functions, ADTs, recursion, maybe types (Option e.g)

Some of those might be more accurately thought of as idioms or even techniques but they're still tools in the toolbox so I've bucketed them together
3 years ago
In terms of formatting consistency an linting, there's plenty of tools available. Scalafmt (https://scalameta.org/scalafmt/) is probably the best.

In terms of approach and syntax choice, it's much harder. I don't see this as any different to Java - people are free to code in a style of their choice and achieving consistency is really a team concern that's difficult for formalise,

There are also tools to help measure the quality in terms of test coverage and code smells (like PMD) but this rely on a common agreement on what "quality" is. For example, you can set a test coverage target of 80, 90 or 100% but the tools can never report if you're actually testing something useful - only that n% of code was exercised during a test.

No easy answer I'm afraid! Best advice I can offer is to work with the team towards a common "house style" and evolve it as you collectively learn. That's true of Java as well as Scala
3 years ago
I see Kotlin more closely related to Java than Scala - it offers a more concise syntax (as does Scala) but less in the way of FP. I think you have to work harder (write your own stuff) to use more sophisticated FP idioms (for example, it doesn't support "higher kinded types").

Kotlin has better IDE support (Scala is so smart - the IDEs struggle to work things out for you!).

Kotlin is set to be the defacto language for Android development as others have said.

Kotlin is still fairly new and as such doesn't offer as mature language features as Scala (for example, the pattern matching and type inference are weaker).

This is worth a read https://dzone.com/articles/kotlin-vs-scala-vs-java
3 years ago
I'm obviously bias but the book firstly compares syntax - like for like. So you'll learn how to convert Java (in your head or in Java codebases) to Scala. Along the way, you'll learn some of the paradigm shift but it avoids in-depth functional programming topics.

The main take away though is that you don't have to change paradigms to use Scala. You can write OO code and use all your existing Java libraries - you just do so with less noise and boiler plate. As you grow into the language, you can pick up more of Scala's libraries (for example, change to Scala's collections) and more "FP" idioms but that can all live comfortably in an OO codebase.

I reflect briefly on my experiences doing the same in the book and try and give some general advice too.

PS. It's totally feasible without reading the book too! Syntax wise, Scala is very accessible and easy to pick up for Java developers IMO.
3 years ago
Often tail recursion in Scala is referred to as tail call optimisation as it is purely an optimisation. The compiler can convert tail recursive code into a loop and avoid stack overflow but in source you will structure your code as a recursive call.

This has advantages depending on your perspective. Writing recursive code (when your head's in that way of thinking) is fairly elegant and easy to reason about. In Scala, this tends to go hand in hand with clear syntax (often, you'll use "pattern matching" which looks really neat and so easy to visually "parse").

Something like the 99 problems is a good way to explore (http://aperiodic.net/phil/scala/s-99/).
3 years ago
Hi,

It took me a while to get my head around the same thing. I love OO for the real world abstractions and couldn't get over the lack of accessible abstractions in FP until I realized FP overs a different level of abstraction. I guess firstly, you don't always need the level of abstraction to be productive with FP... you can think of programs as a collection of _functions_ rather than objects and instances. This takes you so far but I found that you still need to organise your code and structure it properly - something that OO helps you with naturally.

Then as you start to use FP, you start to realize that there are abstractions you can reuse, but they tend to be mathematical in nature. So rather than lift common behaviours into objects (and instances) based on something tangible in the real world, you lift common behaviour into abstract _functional types_. I use "functional types" loosely as I don't know a better name for it. So for example, a _monoid_ is a mathematical terms that describes a certain type of behaviour. When you start using monoids to achieve specific things (I'll brush over the details here), you start to see related things all as monoids. A monoid of your choice may also "be" something else (like a monad) which isn't a classic OO relationship - you can overlay them without the constraints of the real world.

All this shouldn't be a blocker to exploring FP. A lot of stuff on the web talking about Scala and FP will refer to category theory (the branch of maths that offers these kind of abstractions) but you don't need to know category theory to get going. I found lettings these abstractions come naturally as you explore and having a reason to use them worked well. You also never have to leave OO behind with Scala, use real work abstractions where it makes sense (in the large when you're starting) and FP where it makes sense (in the small).

Hope that helps
3 years ago
Yep! Intellij IDEA has one built in. It's fairly manual but if you hit Ctrl + G (on Windows) it will automatically create a Scala file from a Java file (see https://plugins.jetbrains.com/plugin/8457-scalagen-java-to-scala-converter).

The process comes with caveats and you shouldn't expect to be able to convert Java to idiomatic Scala (it will be a literal conversion which isn't always what you'd want).
3 years ago