> > I'm not sure why you thought I was suggesting you were
> > trying to say Scala isn't an improvement over Java. I
> > didn't get that impression. The "irony" I saw was that
> to
> > get at the benefits of the functional style in Java,
> Java
> > syntax actually pushed you in the other direction.
>
> I guess I get that impression because you keep telling
> about features of Scala when I already know Scala, or at
> least all the features you are talking about. Since I
> have tried to make that clear a couple times, it makes me
> think that you are not understanding me. I'm angry or
> anything, I'm just want to communicate effectively.
>
Sorry I wasn't sure how much of Scala you've seen, but also I'm telling others who are reading the discussion who aren't familiar with Scala. But mainly my irony comment was more about how I found it interesting that although you seem to have naturally stumbled upon some of the values that I only discovered when I went to Scala (like preferring little helper methods, avoiding vars, etc.), when trying to write that way in Java, it pushed you in a direction of multiple returns, the opposite direction it pushed me in Scala. The difference is in the language influence, I think. Because Java has mostly imperative control structures that don't result in a value, it makes it harder to
do the seeing methods as single expressions approach.

> > As far as using the boolean variable, that's not me
> being
> > unfair to Java. That's me being true to how I
> programmed
> > in Java for 10 years, and how I think most people
> program
> > in Java from the code I've seen over the years. That's
> the
> > idiom, and returning from inside a for loop, which you
> > showed, would I think be frowned upon by many Java
> > programmers.
>
> And again, this is exactly my point. It's not a feature
> of Java. It's something that people do in Java because
> think Java is like C. Given that Java is not really much
> like C, I fail to understand why it makes any more sense
> to use this idiom in Java than it does to use it in
> Scala.
>
Yes, some of it may be tradition, but how can you tell the difference between when people's preference is because they are used to that way, they were taught that way, etc., versus that they *really* feel that way.

> Are you saying that we must accept this as part of Java
> merely because some people say we should? If developers
> starting using this idiom in Scala does it become part of
> Scala?
>
> > Which rules to you mean? Sorry, can you be more
> explicit?
> > If you mean he rule of having just one return, that
> > doesn't quit add up because in Scala that's also the
> rule
> > of thumb, except that you see it as one expression that
> > doesn't need an explicit return.
>
> The source for List.exists() follows:
>

>   override def exists(p: A => Boolean): Boolean = {
>     var these = this
>     while (!these.isEmpty) {
>       if (p(these.head)) return true
>       these = these.tail
>     }
>     false
>   }
> 

> Caveat: it's possible that the author of this method is
> not familiar with the idioms of Scala or of the single
> return rule of thumb in general.
>
Well, it was probably Martin who wrote that. That's a great example that ties everything together. Pretty impressive. Did you plan that or was it just a coincidence?

Anyway, I would say this is idiomatic Scala in the sense that one of the good reasons for using the imperative style is for performance. There are other good reasons. I think "Scala style" is lean towards functional by default, use imperative when you have a good reason and justification.

List needs to be fast, though I not sure why the while loop being used would be faster than a tail recursive loop that uses recursion, which would have gotten optimized into a a while loop in the binaries. I'm pretty sure it would be tail recursive. Anyway, once they picked the while approach, they would have returned out of the middle because there is no break in Scala. Either you return out of the middle, or you set the flag and keep looping to the end, or check the flat each time through the while loop. The fastest of these would be the return from the middle.

> > I'm angry or anything,
>
> Crud! That's "NOT angry".
>
I'm not angry either. I think we just misunderstood each other a bit, but when you said "I'm angry" I already knew you meant "I'm not angry". So how's that for communication? I guess that's also irony as well, because the literal meaning was the opposite of the actual meaning.

> > Scala was designed in academia, but by a guy who has a
> > very practical outlook and was aiming to solve real
> world
> > problems.
>
> I said as much in my post that you are responding to. I
> did not say no attempt was made. I said the attempt was
> not successful in my opinion.
>
Fair enough. I actually thought of a better example for you, which I'll describe at the end.

> I don't want to be rude but when I look at Scala I have to
> wonder if the creators had any "real world" experience to
> pull from when attempting to solve "real world" problems.
> If not, I then have to question why they believed they
> y knew what the "real world" needs. Even the obviously
> business targeted XML support was in no way what the "real
> world" needed.
>
Martin didn't go out and do surveys or any kind of "market research" that I know of, and I think most of his adult career has been in academia. But he had always been somewhat grounded in reality in that he wrote a compiler that was bought by Borland in the early days, his GJ compiler was bought by Sun and used as javac for many years, etc. But mainly, his goal for Scala was not only that it serve as a vehicle for his language research, but also that it actually be adopted widely by real programmers doing real work. That's different than many academic languages, which are intended more a research vehicles only. He does listen and respond to his "customers," the users of Scala, but during the development of most of it he didn't have many customers to listen to. So how he decides what the world needs may be mostly coming from his intuition and experience.

> > I also didn't know what a fold was before I encountered
> > Scala, but that surely doesn't mean it should be left
> out.
> > It just needs to be explained, taught, learned. And you
> > don't need to use it until you learn it, but of course
> if
> > someone else uses it and you're reading their code,
> you'll
> > have to learn it at that point. But fold is very
> > fundamental and useful and should be learned by all
> Scala
> > programmers eventually.
>
> Again this seems to me like you are not understanding me.
> I never said it should be left out. What I said was that
> t this is unfamiliar to most developers. If Scala is to
> be an accessible language, I think a little more effort
> will be needed explain these features to non-academics.
> Having said that, I haven't read your book yet so maybe
> e this is a bad example.
>
The concept of folds may or may not be such a good example, but the syntax of folds might. There are two ways to do a fold left on lists in Scala, one is called foldLeft, the other /:. Here's how they look when used:

list.foldLeft(z)(op)

versus:

(z /: list)(op)

Even though the latter form has some readability and writability advantages for those familar with Scala and folds, the former one is a lot less scary or wierd looking to someone coming from Java. This fold operator is one of the more common complaints I've heard from Scala newbies, and a lot of people shy away from it. It certainly isn't going to "trick" a Java programmer into thinking this isn't very different from Java.

> Well, it was probably Martin who wrote that. That's a
> great example that ties everything together. Pretty
> impressive. Did you plan that or was it just a
> coincidence?

Just a coincidence, if you can believe it. Lucky for me it was the first thing I looked at.

Honestly, I feel bad for taking this so off-topic. As someone else pointed out, there are probably better uses of my time.

Because Java never used multiple returns ...

 
    public boolean equals(Object anObject) {
	if (this == anObject) {
	    return true;
	}
	if (anObject instanceof String) {
	    String anotherString = (String)anObject;
	    int n = count;
	    if (n == anotherString.count) {
		char v1[] = value;
		char v2[] = anotherString.value;
		int i = offset;
		int j = anotherString.offset;
		while (n-- != 0) {
		    if (v1[i++] != v2[j++])
			return false;
		}
		return true;
	    }
	}
	return false;
    }

You can do this

name.exists(_.isUpperCase)

in every language that supports closures like Ruby, Groovy, Go, JDK8, Kotlin, etc. In Smalltalk this would be something like this:

name contains: [ :each | each isUpper]

And I have never heard any Smalltalk developer calling this functional programming style. Calling simple use of closures functional programming only causes confusion.

Having a single return point is structured -- which gives a simple, uniformity of shape (check: ‘Notes On Structured Programming’/ewd249; Dijkstra; 1970). It should be the default, unless the code can be made even simpler otherwise.

I rate Scala even more compact than Ruby and Python: 86% of the size to be exact! (45% of C++) for full code.

Scala struck just right balance with its type inference, that is: types stated explicitly at function parameters, but not needed elsewhere. OCaml doesn't require them at function parameters, but it is sometimes hard to make it compile -- each time you try to fix it, the error messages change because it infers from a different point.

OCaml changed me a bit earlier, but that prepared me for immediately liking Scala.

> Having a single return point is structured -- which gives
> a simple, uniformity of shape (check: ‘Notes On Structured
> Programming’/ewd249; Dijkstra; 1970). It should be the
> default, unless the code can be made even simpler
> otherwise.
>
> I rate Scala even more compact than Ruby and Python: 86%
> of the size to be exact! (45% of C++) for full code.
>
> Scala struck just right balance with its type inference,
> that is: types stated explicitly at function parameters,
> but not needed elsewhere. OCaml doesn't require them at
> function parameters, but it is sometimes hard to make it
> compile -- each time you try to fix it, the error messages
> change because it infers from a different point.
>
> OCaml changed me a bit earlier, but that prepared me for
> immediately liking Scala.

Just a coincidence, if you can believe it. Lucky for me it was the first thing I looked at here.

Honestly, I feel bad for taking this so off-topic. As someone else pointed out, there are probably better uses of my time.