Newbie question: really confused about ambiguity of the language

[Kosca]

Hi,

I have been using Java for 5+ years, and just started looking into Scala. It is pretty obvious that the language is well thought-out, and covers some serious shortcomings of Java (particularly syntactic overhead). But, one thing that I did not understand and get really confused about is to give developers soooo many options for doing the same thing...

Basically, every time I see some feature, there are 2-3 or even more options for doing it. Just to give an example, you can define a function as:

def foo() = { .. } 

def foo() : Unit = { ... } 

def foo() = ...

def foo() : Unit = ...

Or you can return a value with "return" statement, but also the last statement will be returned too. you can use curly braces, but in some cases you can skip them. You can use semicolon, but it is optional too. Having None,Some,Unit,Null,Nil,null, ....

With closures and placeholders, it almost becomes a nightmare to understand.

Basically, every chapter I read in the book, there are multiple ways of doing something with different syntax, and if two developers have totally different styles, it can get to a point where they won't even understand each other's code. And, this will create issues in a big group. 

Furthermore, this will be OK for seasoned developers, but it will be a nightmare for juniors and people who are just starting out, don't you think?

As I said in the beginning, don't get me wrong. I like what I have seen so far and definitely not trying to bash the language at all. But it is getting to a point where it might be really really confusing to understand someone else's code.

Thanks...

[Alex Cruise]

On Thu, Apr 18, 2013 at 9:35 AM, Kosca <ko...@pismail.com> wrote:

Basically, every time I see some feature, there are 2-3 or even more options for doing it. Just to give an example, you can define a function as:

def foo() = { .. } 

Body is a potentially multiline expression; the return type of foo() is inferred from the last expression in the curlies. 

def foo() : Unit = { ... } 

Body is a potentially multiline procedure, the return type is explicitly stated.

def foo() = ...

Body is a one-line (ish) expression, return type is inferred.

def foo() : Unit = ...

Body is a one-line (ish) statement, return type is explicitly stated.

You forgot this form. :)

def foo() { // the lack of an '=' between the paren and the curly indicates that this is a procedure,
                  // aka a function that returns Unit.

}

Or you can return a value with "return" statement, but also the last statement will be returned too.

Return is discouraged for a variety of reasons.  Depending on where you are in the call stack (including closures), it might need to throw a special kind of exception to escape out to the caller. 

you can use curly braces, but in some cases you can skip them.

Yep. Once you get used to it it's pretty nice. :)

def foo = bar

You can use semicolon, but it is optional too.

Most of us never use them (as statement terminators), except when we want multiple statements on one line.

Having None,Some,Unit,Null,Nil,

 

Those are all different types.  If this were a dynamically typed language, you could get away with using 'nil' everywhere to mean no-value, but it's not.

None and Some[X] are the value constructors for Option[X].

Unit is our equivalent of "void", but lifted into the world of explicit types.

Null is a type, null is a value.

Nil is the empty list object.  Its non-empty counterpart is named "::" (two colons).  A bit cutesy, but it lets us write some nice-looking code.

With closures and placeholders, it almost becomes a nightmare to understand.

It definitely takes some time to learn to read idiomatic Scala.  Many of us who've stuck it out have found it greatly rewarding. :)

Basically, every chapter I read in the book, there are multiple ways of doing something with different syntax, and if two developers have totally different styles, it can get to a point where they won't even understand each other's code. And, this will create issues in a big group. 

Yes, this is why you need to agree on acceptable coding styles in your team.  

Furthermore, this will be OK for seasoned developers, but it will be a nightmare for juniors and people who are just starting out, don't you think?

TANSTAAFL. ;)

As I said in the beginning, don't get me wrong. I like what I have seen so far and definitely not trying to bash the language at all. But it is getting to a point where it might be really really confusing to understand someone else's code.

Been there, done that, STILL get confused reading *some* Scala code after five years.  But I ain't going back without a fight. ;)

-0xe1a

[proyb2]

Not at all, monad, imperative and functional are like worth the learn except for the impatient developers.

[Som Snytt]

You forgot

def foo() { ??? }

let alone

def foo = ???

and

def foo = (
  ???
)

My experience was that it's easy to pick up on "how do I express this in Scala" from among these kinds of choices because the language is so regular.  Especially if you're reading good code as a basis for learning.

What was harder was figuring out, Do I need an underscore here?  Do I need a type ascription?

Please don't start a flame war by mentioning relative imports!

On Thu, Apr 18, 2013 at 9:35 AM, Kosca <ko...@pismail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Haoyi Li]

I had this exact questions a while ago when I was learning Scala. This StackOverflow question (and answers!) should cover most of the cases:

http://stackoverflow.com/questions/8303817/scala-9-ways-to-define-a-method

[Marconi]

Basically, every time I see some feature, there are 2-3 or even more options for doing it.

Well, the same could be said about Java, too:

if (a) {
  b = false;
} else {
  b = true;
}

if (a)
  b = false;
else
  b = true;

if (a) b = false; else b = true;

if (a == true) {
  b = false;
} else {
  b = true;
}

if (a == true)
  b = false;
else
  b = true;

if (a == true) b = false; else b = true;

b = a ? false : true;

b = (a == true) ? false : true;

b = !a; // pick this one

b = !(a == true);

What you mentioned are not different ways of defining functions, they are just permutations of optional parts of a single construct. Optional braces are supported, AFAIK, by all C-style languages. Return types can be inferred or explicitly declared. Empty parentheses may be omitted (with minor differences). Combinatorial analysis tells us we already have 8 different "ways" just there.

Java also has keywords that can be omitted:

interface Foo {
  public abstract int bar();
  int baz();
}

$ javac Foo.java && javap Foo
Compiled from "Foo.java"
interface Foo{
    public abstract int bar();
    public abstract int baz();
}

Pick a style that suits you best and stick to it. Most languages (even Python) do not force any particular style, and that's why there are so many code conventions out there. For a good Scala Style Guide, see http://docs.scala-lang.org/style/

[Marconi]

For the sake of completeness, I forgot

b = a != true;

b = a == false;

:-)

[Kosca]

This definitely has been an amusing thread;) And, thanks for all the replies.

I posted them to illustrate the confusion. I have been reading about them, and I understand the use cases (at least I think I understand them:). But there are so many special cases for every statement / notation / etc, it is hard to remember. And, I can understand and attest to the fact that it will take some time to get used to it and start using these, and I don't expect this to happen over-night.

But, my question is more from a practically point of view. Let me try approaching this from a different angle.

Say, you form a team to develop some project, and you need to grow this team over time. How long would it take for a junior developer to start contributing to the project? With java-like languages, it takes about 3 months for them to get into it and start contributing, and 6-9 months to start writing acceptable code. So, what would this time be for Scala? Or should we just say, do not hire junior developers, but get seniors only;)

Thanks a ton for very useful remarks / comments and explanations once again...

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/18/2013 06:12 PM, Kosca wrote:
> Say, you form a team to develop some project, and you need to grow
> this team over time. How long would it take for a junior developer
> to start contributing to the project? With java-like languages, it
> takes about 3 months for them to get into it and start
> contributing, and 6-9 months to start writing acceptable code. So,
> what would this time be for Scala? Or should we just say, do not
> hire junior developers, but get seniors only;)

Obviously, the better the devs you can get for your team, the better,
but that's true for any language.

On the projects I worked on, the developers, some of them Junior ones,
but all with Java experience, got productive with Scala very quickly.
I can't say exactly how long that took, but probably less than your
Java numbers. (It was a fairly small sample size, and the devs were
all smart, so YMMV.)

At first, the devs weren't writing very idiomatic or functional code,
but that's ok. Writing Java-without-semicolons is a fine way to get
going. We all gradually, and steadily, wrote more idiomatic Scala.
It's been fun!

> But there are so many special cases for every statement / notation
> / etc, it is hard to remember.

As Marconi Lanna pointed out with his/her Java boolean example, there
are a similar number of syntactic permutations for common constructs
in Java as in Scala.

I might even argue that there are /more/ in Java, since there are more
special cases there. One thing that attracted me to Scala was its
regularity and the orthogonal nature of the constructs it supports.
For example, pattern matches are everywhere; learn how they work and
you get assignment, match statements, exception handling, partial
functions, and a sometimes-more-convenient notation for regular
functions, too; there's not a special case for each of those things.

Lots of things in Scala are like that. Compare that with Java, where
plenty of features got added to the language over the years with
backward compatibility strictly maintained. There you have all the
usual C-language-family syntax permutations around optional braces,
etc *and* tons of gotchas involving enums, generics, and whatever else.

TLDR: Relax, it will be ok. Scala is a lot of fun to write in!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlFwdyEACgkQ0GFaTS4nYxsX3gCgoapsX6HTjncq4rX6u/Qu6S1O
Cr0An0v3VfD5yfufqsZ3vf6SiZFWPorE
=qEVT
-----END PGP SIGNATURE-----