[scala] Blog Post: Java is deliberately not programmer-orientated

[Kevin Wright]

I especially like the way that the fourth paragraph refers to  "the conceptual complexity of using it (java)"

followed almost immediately by "it is deliberately simple"

I'm not certain how to best interpret this, but there is an impression here that Java is "deliberately simple" in the same sense as some computer helpdesks, or government paperwork.

So the phrase carries a double-edged meaning.

Overall, I'm in general agreement with the article, and feel that it captures some important points.

Although I fear that the title may be too easily misinterpreted, especially if you don't read the body text...

http://john.freml.in/scala-is-not-a-better-java

--
Kevin Wright

mail / gtalk / msn : kev.lee...@gmail.com

pulse / skype: kev.lee.wright
twitter: @thecoda

[Fabrizio Giudici]

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

On 9/14/10 12:26 , Kevin Wright wrote:
> I especially like the way that the fourth paragraph refers to
> "the conceptual complexity of using it (java)" followed almost
> immediately by "it is deliberately simple"
>
> I'm not certain how to best interpret this, but there is an
> impression here that Java is "deliberately simple" in the same
> sense as some computer helpdesks, or government paperwork. So the
> phrase carries a double-edged meaning.
>
> Overall, I'm in general agreement with the article, and feel that
> it captures some important points. Although I fear that the title
> may be too easily misinterpreted, especially if you don't read the
> body text...
>
> http://john.freml.in/scala-is-not-a-better-java
>

"Java is culturally opposed to these ideas: it is deliberately simple
<http://java.sun.com/docs/white/langenv/Simple.doc.html>."

Well, so I presume I'm not wrong if I infer that "Scala is
deliberately complex"? :-) Happy to see that, since I've been
repeating the same thing for months.

"After the HotJava experiment failed perhaps it's time to admit that
all three major webbrowsers (Mozilla Gecko, Webkit, and Internet
Explorer) are all written in C++ for real reasons and not just force
of habit."

So, what? What would be those real reasons for which Java failed in
delivering a web browser? And given that we're in a Scala discussion,
what's the matter? Does the writer mean that Scala, in opposition to
Java, would be successful for implementing a real world web browser?

- --
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyPUuAACgkQeDweFqgUGxdMEACgtTkw9T54xBxtCCecAmhmLHFa
y+4An0BozC6/E8MZtu5njnRVhZ9FBMKx
=L5vm
-----END PGP SIGNATURE-----

[Ricky Clarkson]

Fabrizio,

I'm not following this thread properly, but I'll just note that Scala
is intentionally simple. It has more features than Java, but less
pointless complexity. E.g. in Java, arrays and generics are
incompatible, generics don't work with primitive types, varargs don't
work with generics (same as the first problem), etc. Scala has none
of these problems. I could probably think of more given more time
than I have right now. I'd at least like to have come up with some
that aren't related to generics!

Ricky.

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1928 706373
Skype: ricky_clarkson

> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
>

[Kevin Wright]

The article obviously uses "complexity" and "simple" in very different ways, they're certainly not portrayed as opposites.

In fact, some effort has been made to show that there's more complexity arising from the "deliberately simple" language.

It certainly doesn't help that both phrases are overloaded in common usage.

Any programming language could be described as both complex and simple, given an appropriate interpretation of these terms.

This does appear to be causing the author a certain amount of difficulty...

Either way, I think the intended take home message is that Scala is best positioned as an alternative to dynamic languages (I'm suspecting Ruby, Javascript and Groovy here) instead of as a successor to Java.  It's a very interesting claim to make, given that Scala is statically typed.

[Kevin Wright]

On 14 September 2010 11:48, Fabrizio Giudici <fabrizio...@tidalwave.it> wrote:

"Java is culturally opposed to these ideas: it is deliberately simple
<http://java.sun.com/docs/white/langenv/Simple.doc.html>."

Well, so I presume I'm not wrong if I infer that "Scala is
deliberately complex"? :-) Happy to see that, since I've been
repeating the same thing for months.

As already stated, there's much here that's open to easy misinterpretation if taken out of context.  The full phrase is:

"... designed to express common programming patterns in a concise, elegant way. Java is culturally opposed to these ideas: it is deliberately simple."

Defined in such a manner, I'll happily agree that Java is simpler than Scala!

Though I'll also add that I don't think this kind of simplicity is desirable.

[Sean Griffin]

I ran across that blog post in my searches a few days ago, but I only
read the first couple paragraphs at the time. I fully agree that the
title is misleading with a subtle point that:
1. If used as a slant toward sarcasm is a point most will miss or
2. If stated as a true opinion, it's one I don't agree with

Maybe the right title should be "Scala is not ONLY a better Java".

Many of the arguments used to prove complexity point to DSLs, which
are *very hard* to do right and most people should not tread into that
capability lightly. So ok, let's throw them out of our mind for a
little and just look at some of the things left over, that IMHO, lead
directly to "a better Java":

1. Type inference
2. Immutability by default
3. Consistent application of object-oriented principles (i.e. no
protected statics which don't make sense, no direct difference between
primitives and object forms)
4. Case classes to automatically create entity classes with getters
and optional setters, guaranteed accurate equals and hashCode
implementations - all with 1 line of code
5. Closures
6. Strings-in-switch (one use of pattern matching)
7. A truly beautiful collections library

You get all these features, on the JVM with all the features that
gives you, and interop with Java libraries. If this isn't a better
Java then nothing is. But I do agree with the author's points that
Scala, the *language* has different goals than Java. But if I
remember back to my days when I switched from C++ to Java, the
language was not my main reason. It was other things, like a way to
do GUI in the same language that I could write console/server apps
(unlike VB), the ability to write rich web applications through
applets (later replaced via DHTML libraries but at the time an
intriguing option), and MEMORY MANAGEMENT!!! All that with a similar
syntax to C++. That C++-based libraries really never took off in all
those years, while Java libraries mushroomed immediately just stamped
the language in place. With the ability to keep the powerful JVM in
place while there exists an option to look at different languages
that, when you throw out the DSL stuff, still leads to a better Java,
I think it would be irresponsible for us to not at least take a real
look.

[Sean Griffin]

Ok, it wasn't my intention to change the subject...not sure how that
happened. Also, I think I was incorrect about setters on case
classes...not sure you can actually do that. It's been a few months
since I've actually programmed in it. I just review everyone else's
code these days...

[Reinier Zwitserloot]

This argumentation of "If you don't like the DSL stuff don't use it"
isn't convincing, at least not for me.

You can't just throw out half of a language. I have to look at code
written by others. I want to use libraries that say "for Scala" (or
even: "For JVM"). I don't want to wait for a library that says "For
Scala, and, oh, we don't use those particular features you didn't
like". That doesn't scale in a world where code is shared between more
than 1 developer.

Also, if you want accurate equals, hashCode, getters, and setters,
then, use Project Lombok. Strings in Switch will be coming in the now
accelerated JDK7 (It's one of the features already completed). Use
guava for a nice collections library. The few places where scala does
significantly more type inference than java are either rarely
applicable, actively disliked (in my experience) by those who would
like to "throw out the DSL stuff", or it's inference of generics in
variable assignments, which is also coming in JDK7 (diamond operator
is also finished and won't have to wait for 8). That's most of the
features on that list covered already, without having to do anything
as drastic as switching to an entirely new language.


If you're going to go with scala, go whole hog. I don't see the point
of using scala as a java with slightly more cleaned up syntax. It's
not worth the trouble of switching if that's all you're going to do.

[Sean Griffin]

There's a fundamental difference between writing a library and
consuming a library. My point was two-fold:
1. People say Scala is complex, but the actual examples that attempt
to prove this complexity are rare. Features that support *writing*
DSLs are often used as those examples. I've done a fair amount of
Scala development. I have yet to write a DSL.
2. Capabilities that currently exist in Java are simpler in their
Scala equivalent

I never said you can't *use* a library that uses DSLs. Actors are a
DSL, and they come with the core scala-library. Certainly use them!

I won't be able to use Java 7 for probably 4 more years. I can't even
use Java 6 yet because I have to remain compatible with a Java 5 JRE.
Lombok could give me easier data classes but wouldn't allow me to use
them in pattern matches. Google's collection library is great, and
Lombok sounds pretty good, too. But I think that was slightly
tangential to my argument. I was discussing the content of the blog
post and not really saying that everyone should switch over to Scala,
only that it's worth a serious look.

Finally, the whole "drastic as switching to an entirely new language"
argument doesn't hold much water with me. Learning the language is a
one time thing. Learning each new library's API or framework,
regardless of the language, is a continual thing and we never question
that! I write software in Java, SQL, a proprietary scripting
language, Batch scripting, JavaScript, Visual Basic, C++, XSLT while
also interfacing with RTF and XSL-FO. Nevermind the frameworks and
other libraries I have to use and the real-world challenges I have to
solve using these technologies. Adding Scala to the mix is nothin'.

[Vince O'Sullivan]

On Sep 16, 4:42 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> ...will be coming in the now
> accelerated JDK7...

What are you referring to by "accelerated"? All I seem to read about
JDK7 is delays.

[Ricky Clarkson]

Reinier,

A number of DSL-heavy Scala libraries provide a more conventional API too.  I think this makes sense at least for those who are only touching on that domain, not using it a lot.  I'd rather there was some way of importing the methods as implicit conversions or something than the library writer having to have duplicate API.

import java.util.ArrayList.{sort => (_: java.util.List).sort}, in my imaginary syntax, would make calls to List.sort (which otherwise doesn't exist) end up calling ArrayList.sort.  It would also need imports themselves to be importable to be generally useful.

Hmm, I can already see hordes of people shouting this down.  Possibly including me.

[Kevin Wright]

+1 

If you're going to adopt a higher-level language, then it does seem odd that you'd not embrace some of the best it has to offer.

Just consider other features beyond the "cleaner Java" list: partial functions, deep function/object integration, xml literals, implicits, higher-kinded types, extractors, by-name parameters

Some of these are clearly on the "advanced: use with caution" list, but others you won't even know you're using, they're that well integrated.

If you thought closures were neat, try this trick:

val predicate = Map("apple" -> true, "banana" -> true, "lemon" -> false, "orange" -> false, "pear" -> true)

val fruitList = List("apple", "apple", "pear", "orange", "pear", "lemon", "banana")

val noCitrus = fruitList.filter(predicate)

The magic is in Predicate, which is defined as a Map.  But, and this is the clever part, Map is a subclass of Function1.

So whenever a function from X => Boolean is called for, you can supply a Map[X,Boolean]

All functions are objects, and any object can be a function, it's a very powerful combination of features.

Having said all of that.  Using Scala as a clean Java is a perfect way to start with the language.  You can then ease into the other features gradually.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

The plan by Oracle is to take the current planned features for JDK7
and cut these in half. Whatever's done or nearly done goes in JDK7,
which can then be released much sooner (later than the planning, but
those paying attention to it have known for a while now that it was a
deadline nobody took seriously), with the remaining features moved to
a JDK8.

[Reinier Zwitserloot]

On Sep 16, 6:22 am, Sean Griffin <trenchgui...@gmail.com> wrote:
> 1. People say Scala is complex, but the actual examples that attempt
> to prove this complexity are rare.

No they aren't.

> Features that support *writing*
> DSLs are often used as those examples.  I've done a fair amount of
> Scala development.  I have yet to write a DSL.

You've written in DSL plenty of times already. Ever omitted the 'dot'
when dereferencing? Ever decided not append "()" to a method call that
doesn't require any arguments? You're a winner already! The DSL nature
of scala does in fact leak out more during using a library intended to
be used that way than vice versa. Operator overloading, omission of
dot for dereference, omission of parens, the underscore shortcut when
inline-specifying a closure, these are what are meant (or at least,
what I mean) when I refer to scala's DSL features, and these are ALL
things that are to be typed by the USER of a library, not the writer
of one. Unlike e.g. generics wildcards which casual use of a library
won't ever bother you with.

> 2. Capabilities that currently exist in Java are simpler in their
> Scala equivalent
>

You keep using that word, "simpler". This discussion is a lot more
nuanced than that, unfortunately. What you keep calling "simpler" I
tend to consider more complicated. And yes, I've used scala, rather a
lot even. I'm not equating "simpler" with "doesn't look familiar".
Until you define what you mean with simpler, I don't think this is
going to get past the "he said, she said" phase.

>
> I won't be able to use Java 7 for probably 4 more years.  I can't even
> use Java 6 yet because I have to remain compatible with a Java 5 JRE.

But staying cutting edge on scala is legit? Talk about using two
yardsticks. You're actually going with "scala is better because its
more stable"? Good luck with that argument.

> Lombok could give me easier data classes but wouldn't allow me to use
> them in pattern matches.

Ah, yes, just keep moving the goalposts, I forgot.

> only that it's worth a serious look.

In contrast to, let's say, groovy, jruby, or jython? Are those not
worth serious looks?

>
> Finally, the whole "drastic as switching to an entirely new language"
> argument doesn't hold much water with me.  Learning the language is a
> one time thing.

Of course it isn't. That's ridiculous. Scala revs fast (an argument
being used by e.g. Kevin to convince people to switch, no less!). I
need only point at scala 2.8 which is a massive update, for example.
Even if scala didn't rev like its a fairly new language, there's the
community. They release new, major libraries all the time. Styles
change, too. Even java has this quirk: 5 years ago, the builder
pattern wasn't all that famous and methods returning self so they
could be changed where quite rare. Now you see them everywhere. joda-
time and guava are used in lots of places, but they didn't exist 5
years ago. Somebody's kicking the tires on the web framework world
every other year, it seems. Scala is of course no different.

Long story short: Claiming that learning a language is a one-time
investment is a falsehood.

This isn't a bad thing, but it does highlight yet again what I keep
saying: If you're going to switch to scala, then switch. Going halfway
is not a good idea.

Any product you can write in scala, you could write in java, and vice
versa with no more than a ~25% productivity loss, and that's in rare
and extreme cases. The "right tool for the job" is not useful in such
a scenario. The effort in keeping up to date at two languages costs
you more in total productivity loss using either language than what
you gain by being able to switch to the one that's better suited at
the job. No, if you're going to go down this path, you should learn
javascript (because html+web is something completely new from giving
people a swing app to download, for example), or javafx (because
writing certain GUIs in javaFX is easily 2 to 3x faster than doing so
in swing), or a new web framework, or something like haskell (more to
learn more about writing code in java/scala than actually add a tool,
but that's good too!)

> Learning each new library's API or framework,
> regardless of the language, is a continual thing and we never question
> that!

Scala, by for example replacing the collections library, means you
need to not just learn a new language, no, you've got to learn an
entirely new API too. Yes, you can interop with java's libraries, but
then you're on your own. The vast majority of java programmers can't
read your stuff very well because its scala, but the vast majority of
scala users don't really want to mess with your code because its using
non-standard libraries. This doesn't work. You need to switch over
completely, as I keep saying.

Technically the idea of a java clone that just cleans up a few issues
may even work (I doubt it'll be compelling enough to cause many people
to switch), but at the very least such a language will not introduce a
significant amount of new API. Scala is not that language. Scala is a
major change from java. Most actually prefer it that way.

[Miroslav Pokorny]

It seems to me that people focus too much on the language and forget about the libraries and what not. Nearly every example is very concentrated on showing a terser way of passing a closure and so on. It also seems to me that people forget all the great libs that are easily usable from java and ignore these sort of integration issues etc from other platforms. What happens tomorrow when Scala closures and java ones are incompatible ?

[Dominic Mitchell]

On Fri, Sep 17, 2010 at 3:13 AM, Miroslav Pokorny <miroslav...@gmail.com> wrote:

It seems to me that people focus too much on the language and forget about the libraries and what not.

True.  But is this the Java Posse, or the JDK Posse? :)

-Dom 

[Ricky Clarkson]

Reinier,

You want a definition of simple?  Ok, some code is more simple than some other code if it contains fewer tokens that are outside the domain.  E.g., Cobol's ADD 1 TO AGE GIVING AGE is not as simple as C's age++.  Java's SwingUtilities.invokeLater(new Runnable() { public void run() { button.doClick(); } }) is not as simple as Scala's: doLater(button.doClick).

Staying cutting edge on Scala is easier as it does not require a cutting edge runtime.

In my opinion, for tasks for which Java is a reasonable option, so is Scala, as it is typed and runs in the same environment.  I wouldn't look at Groovy, JRuby or Jython for those, because they are untyped.

Regarding writing in DSLs, pretty much all code unless it is spaghetti ends up being written in a DSL.  For example, at college I saw plenty of Pascal users writing lots of lines like:

gotoxy(3,4);

write('|');

gotoxy(5,6);

write('-');

to draw ASCII forms etc.  I wasn't actually studying computing at the time, so I didn't have to write any of that code, but it seemed logical to me to make a procedure writexy(x: Integer, y: Integer, char: Character) to write the above as:

writexy(3,4,'|');

writexy(5,6,'-');

That is, I invented a DSL and used it, without knowing what one was.  It has nothing to do with missing out a dot in Scala.

(Incidentally, Pascal was the first semi-colon delimited language I came across after years of BASIC, and I was learning it by following the compile errors.  The compiler told me it was expecting a ; at the beginning of the line, so that's where I put them!  I got some funny looks when I showed the Computing students that code)

Regarding productivity loss or gain from moving to Scala, I did screw up one project by doing this, but that was more to do with my then lack of good engineering practices.  For example, I had moved from 20031112-source.tgz style 'version control' to darcs, and then moved to Windows, where darcs was not then supported very well, so I went without version control for a while (the real issue being that I had no server to speak of to store code).  That was manageable, though not ideal, but when I moved to Scala I could really have done with 'game save points'.  As a result I went some months porting to Scala without a successful compile, and being unable to roll back to a working point.  Eventually I got it compiling and all the unit tests running again, but the UI was in tatters.  I still hope to resurrect it (I was allowed to make it open source when I left, meaning I could finally host it on a public svn/git server, oh the irony).

I expect nobody on this list is at the point I was then; we probably all use version control and use it reasonably well, and it is easier now to port to Scala than it was, as Scala can do mixed-language compilation (by being able to parse just enough Java).  Thankfully it was a pretty low risk project, but it did sadden me.

Since then I've only had benefits from using Scala, but then I have become competent in version control, I now use tickets to manage tasks instead of emails or bugs.txt files in the codebase, and perhaps more importantly I'm kept honest by the fact that I'm expected to make releases all the time.  The project I screwed up was only used from February to May every year (apart from some random people in Colombia who got hold of it).  I don't think the screwup was Scala-specific at all, I'd have made the same mistakes porting to any language.

Your point about Scala users being uninterested in your code because it uses Java libraries seems completely false.  Most Scala programmers are very good Java programmers, and probably over half of them know Java's standard library better than Scala's.

[Reinier Zwitserloot]

That just sounds like equating "simple" to "less verbose".

For example, with optional () for args-less method calls, you get a
number of things which one might deem "simpler":

- Less characters to type and read
- The ability to not have to care about whether the doClick member is
a method or a field

On the other hand, you also get a few things which are decidedly more
complicated:

- A stylistic choice about whether or not you add the (). Having to
make an irrelevant choice of any sort clearly seems like a lack of
simplicity to me.
- The INability to tell if doClick is a field or a method. In certain
circumstances it matters, and having to look it up is more complicated
than being able to tell at a casual glance.


These are clearly conflicting requirements. Forcing you to care
whether doClick is a field or a method is needless complexity....
unless it isn't, in which case not being able to tell is needless
complexity. Offering the programmer the choice doesn't help, because
the choice in it self is needless complexity, and by existing we still
can't tell, given "foo.doClick", if doClick is a field or a method.
We'd have to rely on a programmer following the local style guidelines
(if, say, these state that non-fields ought to be called with parens),
which you can' even unit test. Now we're introducing needless
complexity there.

Oh, how complicated.

There's also the issue of moving complexity around to the problem
domain. My usual retort to those complaining about the complexity of
generics is simply this: Co- and Contravariance is _inherently_
complicated. When you have a problem where generics is required or
seems quite useful, then the problem has this complexity, inherently.
You can choose not to use generics, but then the complexity is just
hidden away in javadocs and a bunch of casts. You can tweak generics a
bit, declaration-site generics probably being the most drastic, but a
truly "simple" generics will never be, because co/contravariance isn't
simple.

So, did java become more complex when 1.5 was introduced? Yes. Does
this mean java 1.5 is worse than 1.4? No - in fact, it's better.

So, in certain ways, a more complex language is actually a good thing.

Hence my conclusion that all this talk about "complexity" is not going
to convince anybody one way or another, because its very very easy for
anyone reading the word "complexity" and imagine whatever situation is
least likely to convince them.

So, to try and mitigate this, here's where I believe scala has added
needless complexity:

Stylistic choice is EVERYWHERE. This is what, as I said, *I* mean by
DSLish features (yet another vague term that can mean just about
anything). Should I put () after an args-less method call? There's a
stylistic choice there. dots to dereference? Another stylistic choice.
Use operator overloading, or not, and if I do, left-associative or
right-associative? There's also boatloads of semantic choice in scala.
If I need to iterate over a map and, say, produce a list containing
the concatenation of each key and associated value, in java there's
really only two obvious ways to do it. Both involve looping, and the
only difference is whether I iterator over entrySet() or keySet(). In
scala, there's _way_ more choices. I can do a java-style loop, or I
can use an each construct that fills the list, or I can turn the keys
and the values into two sets, and then zip them up, functional style,
or I could use a comprehension of some sort.

Why is this bad:

Well, obviously a language can't eliminate _all_ stylistic choice. At
the very least you have to pick a name for your methods, and naming is
clearly up to you, the API author. But, scala goes _way_ too far in my
opinion. While it seems like a nice idea, give an API designer, and an
API user, the ability to write in whatever feels most natural (i.e.
readable, easy to maintain), that's great! Except when it isn't: By
introducing all these stylistic choices, you're forcing the API user
to pick at every stage. Sometimes, this choice is good, because the
benefits of picking the best option available outweigh the burden of
having the choice. In all other situations, though, this choice is not
useful at all. It makes sharing code harder (because Joe likes 'each',
but Jack likes 'for'). This is like spaces v. tabs: The flexibility of
using either really isn't helping. We'd have been better off if back
in the day someone put their foot down and declared some indent style
to be the only one compilers will accept from here on out. Deviation
from this one rule results in compiler warnings. I can't claim to be
very scientific about it, but to me it feels like Scala has gone
waaaay too far down the "give the programmers the flexibility" path.
Where the flexibility helps me make code do different things, that's
fantastic. Where this flexibility boils down to the exact same end
result, and I just have many different ways of expressing the same
concept, usually, it's just a bother. It's needless complication.

The python folks differentiated themselves from the Perl folks early
by turning Larry Wall's "There Are Many Ways To Do It" around into
"There Is Only One Way To Do It" and I subscribe to the theory.
Introducing stylistic choice needlessly is always bad. But yet again
there's a dichotomy here: Where stylistic choice turns from pointless
to useful is a moving target, there isn't a single answer to the
question.

Perhaps I was unclear about my comment in regards to using java
libraries in scala code: If you're going to write scala, then... write
scala. Which means you use THEIR collection APIs. If you stick with
java.util.List, then interopping with other scala code is going to be
a nightmare, and even if most scala programmers are familiar with the
java APIs (which is clearly an argument that can't scale: If scala
outgrows java in popularity, or gets even remotely close to it, how
can that possibly be true?), its like not following the camelcasing
conventions in java code. It throws people off, makes your code
ridiculously hard to understand. Just don't do it. There's no going
halfway, and there's not much point (as you said too) in trying to
stay up to date with both java and scala. Pick one. That's your go-to
language for larger projects where static typing is nice, and/or speed
is not unimportant. If you want to learn more languages, fantastic.
But don't pick java and scala. That's a silly combination, the problem
domains where these 2 languages shine overlap far too much.

> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> > .

[Ricky Clarkson]

I agree that optional empty parameter lists are a bad idea, but for slightly different reasons.  If, as in Python, Scala made foo always just refer to something, and foo() always call something, that would simplify some syntax, probably even making the standalone _ unnecessary (val referenceToPrintln = println _).  It would of course get rid of the possibility of each coder doing it in a different way to each other, but you have that kind of choice all over programming.  Even if you removed it from everything you can think of, each person would still differ.  That's why you have to actually collaborate and read each other's code.  But sure, technical solutions exist for enforcing some elements of style.

It would, however, mean Scala would have to drop the uniform access principle, in which all public Scala fields get an accessor and mutator (if appropriate) automatically and calls that look like they are reading the field directly are actually calling the accessor, allowing one to change the internal representation without changing client code.  So I'm not suggesting it for Scala, but in any new language.

I'm not especially bothered about punctuation in my definition of simple, though.  I'd argue that non-punctuation tokens, where they aren't in the target domain, take more away from readability, as in my invokeLater example Runnable, public, void and run are clearly irrelevant to understanding what the code *means* rather than what it *does*.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Kevin Wright]

Java-the-platform posse? :)

 

Given the recent Apple announcement, I guess this might even include iOS now, if you allow for cross-compilation...

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

I'm recently taking the position that it's impossible to state which of two languages is "simpler", the term is just too heavily overloaded.

 

Just pick your definition and it's trivial to show that assembly is simpler than LISP, or vice-versa, but you've still achieved nothing.  If we use the term "higher-level" instead of "simpler", then this difficulty evaporates.

 

Personally I feel that Scala is simpler than Java, but that statement means nothing without also explaining the particular definition of the term that matters to me.  In this case, it's two features of that language that really stand out, and show Scala to be the higher-level language..

 

1. It has constructs that closely match the way I think about problems.  When I have to mangle the design in my head so that it matches the features of the target language, I perceive that as an unneccessary complication in the design+implementation process.

2. Scala has a smaller general-purpose syntax that I can use accross a wide range of problems, instead of a larger number special-case constructs.  For example:

 

- Java has the ?: operator, but Scala has the much more general idea that all expressions return a value.

 

- Java has a switch statement over numbers, enums and (soon) Strings, wheras Scala has pattern matching that isn't limited to any type.

 

- Java has primitives, and operators are limited to only working with primitives.  Everything in Scala is an object, and operators are just methods.

 

- Java has special behaviour for concatenating an object or primitive to a string, Scala can do this with implicit conversions - a feature that's useful in many more situations.

 

- To fetch a value from an object in Java, I must first know if it's a fixed value or if it'll be calculated, and so use field or getField() as appropriate, Scala doesn't force this distinction and so it's enough to know I'm fetching a value, the underlying logic could even be changed in the future without breaking my code.

 

The ability to work with general concepts and not have to chose exactly which special feature I need in a given situation... I see that as simplifying the task of programming.

I could say more, but it's probably just "simpler" to point here: http://stackoverflow.com/questions/727078/whats-so-great-about-scala/3713401#3713401

 

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

Correction: In java, as in scala, all expressions "return" a value
(not really the right term, that. Expressions *have* a value is closer
to the mark). It's just that in scala more things are expressions.
Like "if": Expression in scala, statement in java. Not ALL things in
scala are expressions. Variable declarations aren't, for example.

In any java library that isn't completely worthless, the code is
"getField()". If you get annoyed at writing out the accessor, use
lombok. Claiming that as a benefit to scala seems like you're grasping
for reasons.

A useful definition for "higher level" is that it makes invisible /
automated whatever's trivial detail. This is a double-edged knife,
though: Whether or not a detail is trivial depends on the problem. For
example, C conveniently abstracts away the concept of stack, but in
the process of doing so, removes the ability to store stacks. The JVM
abstracts away memory management, but in the process of doing so
introduces non-determinism due to gc runs.

However, with that definition scala isn't much higher than java. There
aren't many things that you can no longer do in scala but which you
can do in java, and on the flipside, there aren't many things that are
orders of magnitude simpler in scala than java because something has
been abstracted away. Scala is more a sideways step: It's operating at
the same general level of abstraction as java, but with a different
syntax, which includes more emphasis on function objects (something
java CAN do, but not with particularly nice syntax), as well as a less
rigid syntax structure, and a general more functional outlook.

> I could say more, but it's probably just "simpler" to point here:http://stackoverflow.com/questions/727078/whats-so-great-about-scala/...

> ...
>
> read more »

[Kevin Wright]

On 17 September 2010 16:18, Reinier Zwitserloot <rein...@gmail.com> wrote:

Correction: In java, as in scala, all expressions "return" a value
(not really the right term, that. Expressions *have* a value is closer
to the mark). It's just that in scala more things are expressions.
Like "if": Expression in scala, statement in java. Not ALL things in
scala are expressions. Variable declarations aren't, for example.

Hot from the Scala REPL:

scala> val x = { val y = 32 }

x: Unit = ()

So even variable assignments evaluate to a value.

 

In any java library that isn't completely worthless, the code is
"getField()". If you get annoyed at writing out the accessor, use
lombok. Claiming that as a benefit to scala seems like you're grasping
for reasons.

It's a major benefit:

trait X {

  def property : Int

}

class Y extends X {

  val property = 32

}

When I use `property` from an object of type X, it really doesn't matter if it's implemented via a field of if it's computed.

That freedom from having to know (or care) is a simplification to me.

 

A useful definition for "higher level" is that it makes invisible /
automated whatever's trivial detail. This is a double-edged knife,
though: Whether or not a detail is trivial depends on the problem. For
example, C conveniently abstracts away the concept of stack, but in
the process of doing so, removes the ability to store stacks. The JVM
abstracts away memory management, but in the process of doing so
introduces non-determinism due to gc runs.

However, with that definition scala isn't much higher than java. There
aren't many things that you can no longer do in scala but which you
can do in java, and on the flipside, there aren't many things that are
orders of magnitude simpler in scala than java because something has
been abstracted away. Scala is more a sideways step: It's operating at
the same general level of abstraction as java, but with a different
syntax, which includes more emphasis on function objects (something
java CAN do, but not with particularly nice syntax), as well as a less
rigid syntax structure, and a general more functional outlook.

Function objects are just a tiny part of it, not only does Scala have functions that are objects, but also any arbitrary object can be made into a function.

On top of this there's pattern matching, implicits (which allow for type classes), higher-kinded types and by-name params.

Closures alone don't make a language higher level than Java, but Scala really isn't about just closures...

Just compare the implementation of a heterogenous list in both languages:

http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the-limits-of-the-java-type-system/

http://apocalisp.wordpress.com/2010/07/06/type-level-programming-in-scala-part-6a-heterogeneous-list%C2%A0basics/

 

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Ricky Clarkson]

That's an interpreter illusion; a variable declaration is not actually a value, otherwise you would be able to write:

def x = val y = 5

[Steel City Phantom]

i am so bored with this subject that i wish people would just drop it.  java is not developer friendly?  are you serious?  on this subject, its not java that isn't developer friendly, its the supporting libraries that suck.  my god even with auto code generators hibernate blows as far as friendly.  the way it should be is you have an annotation at the top of the container class with saying what table its mapping and your ant or maven script has the connection information to the database and at compile time that script logs into the db, pulls a create script from the table and uses that information to write the appropriate byte code.  if you want to override the default, fine, annotate a field with an enumeration or something but 99% of the time defaults are fine.  THATS developer friendly and it has nothing to do with java.  the argument would be the same wether is java, scala, groovy, php, c#, vb, c, c++, or assembly.

right tools for the right job.  im a java developer.  i have been doing it for 9 years.  i think in java.  you give me a problem, i think of the solution in java.  does java have its limits, absolutely, so does every other language.  but i know what those limitations are and coding around them is simply second nature.

is scala impressive? absolutely.  but my biggest problem with scala is one of the things most people cheer.  its rapid release cycle.  ive been working on the same project for 8 years now.  we finally finished an integration project to get us out of jvm 1.4 and on to jvm 5.  it took a year and a half to implement all the upgrades on our code and the only reason we did it was we had to start running jboss seam and it just straight up doesn't work on 1.4.  if that requirement didn't come up, id still be coding on 1.4.  trust me, 8 years and well over a million lines of code in my project, change is not good and if you were to ask me to do something this big again and choose a platform, i would choose java over scala simply because java changes very slow.  i know every straight out of school code monkey believes that latest really is the greatest, but us guys that have been doing it forever can appreciate that sometimes ol reliable is the best approach.  if you want a practical example, how many of you still work with cobal from time to time?  

now as far as developer friendly, all you have to do is look at spring.  i quit using it years ago because its just to damn ridiculously complicated.  i started realizing i could just code the problem by hand on my own faster than i could figure out some poorly documented over featured, overly complex library in spring.  is that java's fault? absolutely not, its the libraries fault. and you will have the same problem no matter what language you use.

and don't get me started on configuration xml's.  you want developer unfriendly you can stop right there.  especially if you work with an app server.  do they have to be that complicated?  absolutely not.  you could do exactly the same thing with simple annotations and reduce your entire J2EE app config files down to one file that simply has your DB connection info.  

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You want it fast, cheap, or right.  Pick two!!

[Kevin Wright]

precedence rules are catching you out here, you need the braces:

def x = { val y = 5 }

It also works just fine in compiled code

[Cédric Beust ♔]

I agree with everything you said except this particular point:

On Fri, Sep 17, 2010 at 8:18 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:

In any java library that isn't completely worthless, the code is
"getField()". If you get annoyed at writing out the accessor, use
lombok. Claiming that as a benefit to scala seems like you're grasping
for reasons.

I think properties are a big deal and the little syntactic sugar they add helps reduce noise considerably.

Actually, when I try to think of the top three features I'd like to see in Java, they are, in order of decreasing priority:

1. Properties
2. Closures
3. ...

Of all the languages that implement properties, I think C# has the best syntax but Scala's is also great. I particularly like the class constructors and the case class constructors, both of which capture very elegantly what I want to do with my classes most of the time (take a few key values in the constructor, store them in fields and expose these fields as properties).

Notice that I didn't fill item 3 above because I just can't come up with a feature that I think is as important as the first two. I'm leaning toward traits.

--
Cédric

[Kevin Wright]

I can say with all honesty that I have never worked with cobol.  I did a little pascal once, but quickly distanced myself from it at the first given opportunity.  :)

As a Java developer for over 12 years, it only took me about one year of *properly* using Scala for Java to feel like a foreign language

I was also a very early adopter and proud advocate of Spring, but still feel that, at the time, it was the right solution for the problem (i.e. a dynamic config framework without the boilerplate of EJB).  Thankfully the state of the art has progressed since then...

So one question for you:  If you decided to stop using Spring, but change isn't good, then was it a bad decision?

[Cédric Beust ♔]

On Tue, Sep 14, 2010 at 4:28 AM, Ricky Clarkson <ricky.c...@gmail.com> wrote:

Fabrizio,

I'm not following this thread properly, but I'll just note that Scala
is intentionally simple.  It has more features than Java, but less
pointless complexity.

Saying this without mentioning that Scala adds complexity of its own as well is a bit disingenuous, and it's also the reason why strong Scala advocacy tends to turn people off rather than getting them interested in the language.

A couple of examples (about comprehensions, since I just encountered these recently so they're fresh in my mind):

• In a for expression, if you declare a variable, you must omit "val".
• The following syntax is invalid:  
  for (a <- accounts if account.id % 2 == 0) { yield a }
  (yield can't appear there)

I find oddities like these ones in the Scala grammar *all the time*, and to me, they are the sign of a language that's growing too big. I can deal with them, and obviously, so can you, but this is very much reminiscent of C++ to me:  a language that's so complex that organizations that adopt it must agree on which features *not* to use in order to keep the code base sane.

-- 

Cédric

[Casper Bang]

> now as far as developer friendly, all you have to do is look at spring.  i
> quit using it years ago because its just to damn ridiculously complicated.
>  i started realizing i could just code the problem by hand on my own faster
> than i could figure out some poorly documented over featured, overly complex
> library in spring.

Watch out, it's highly unpopular to criticize Spring. To me it
represents all that's wrong with Java, the fact that the JRE libs are
so bad that we have to replace each and every imaginable corner. I
ditto you on the fact that writing it by hand is simpler, more
efficient and more fun. However it seems to be one of those things
that completely divide the waters, it certainly does in my department
at work.

[Reinier Zwitserloot]

Ah, that was it; variable declarations are expressions but their value
isn't what you might think. I knew there was some reason for not
trying to use them as one.

Your extends example doesn't make any sense to me. It's the same in
java:

interface X {
int property();
}

class Y implements X {
public int property() {
return 32;
}
}

I gave you a useful definition of 'higher level'. I don't really see
how saying "But I think scala IS higher level" without either defining
what you mean or giving examples that fit my particular definition is
a good idea, given that we just got into a 200+ post mess due to
confusion about the term "complexity".

On Sep 17, 5:50 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:

> Just compare the implementation of a heterogenous list in both languages:http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the...http://apocalisp.wordpress.com/2010/07/06/type-level-programming-in-s...

> ...
>
> read more »

[Reinier Zwitserloot]

Well, all I can say is: Check out Project Lombok :)

Even properties is a vague term. Which pick-n-mix from this selection
of properties (heh) of what folks tend to mean when they say
"properties" are you interested in:

1. Simple syntax, or even completely automated, generation of getX and
setX(T) methods for any declared field.

2. Translating "x.foo = y" into x.setFoo(y), and the same for getter
access, either completely automated, or only if 'foo' is marked as
property somehow.

(Technically one could also imagine a scenario where the methods are
an implementation detail you never see, like e.g. python, but on the
JVM that's never going to happen, so, I've split it up like that).

3. Simple syntax, or even completely automated, generation of
addPropertyListener or addFooChangeListener and associated methods
including firing these listeners when the setter is called.

4. Library or language feature to let you bind any two properties
together (one changes when the other changes, and if you want, vice
versa too).


Lombok only does #1 for you. But #2 I find irrelevant (you save no
typing, and you do obscure an implementation detail which is
particularly important within the class containing the property), and
#3 and #4 very cool, but not something scala does as far as I know.

Java HAS closures right now, they are just unwieldy. An anonymous
inner class is a portable code block that closes over the state of its
immediate context. It's just that, while it understands you when you
e.g. write to a variable from outer, it then generates a compiler
error. It still closes over state, and you can thus use this feature
to accomplish everything you can do with closures. I grant fully that
syntax needs thorough cleaning up, but "higher level" does not seem to
apply.

On Sep 17, 6:51 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> I agree with everything you said except this particular point:
>

> On Fri, Sep 17, 2010 at 8:18 AM, Reinier Zwitserloot <reini...@gmail.com>wrote:
>
> > In any java library that isn't completely worthless, the code is
> > "getField()". If you get annoyed at writing out the accessor, use
> > lombok. Claiming that as a benefit to scala seems like you're grasping
> > for reasons.
>
> I think properties are a big deal and the little syntactic sugar they add
> helps reduce noise considerably.
>
> Actually, when I try to think of the top three features I'd like to see in
> Java, they are, in order of decreasing priority:
>

>    1. Properties
>    2. Closures
>    3. ...

[Miroslav Pokorny]

Properties are in the end syntactical sugar, they dont add any real behaviour differences on top of a getter/setter. Why does it even matter, when with most modern IDEs, writing there are minimal keystrokes counts to type in a getter or setter. If one does the right and makes all their objects immutable, setters are gone. If builder setters are named property() and getters the same the keystrokes are almost identical... So why all the fuss ?

[Cédric Beust ♔]

On Fri, Sep 17, 2010 at 8:27 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:

Well, all I can say is: Check out Project Lombok :)

I think Lombok is a non-starter for a lot of organizations just because it's basically its own compiler.

Even properties is a vague term.

Maybe, so let's be concrete: properties like C#.

The short version: uniform access principle.

The longer version:

I want to be able to write "a.name = foo" and not have to worry about implementing a getter and a setter until the day where I actually need one. When I do, I just implement it and all clients automatically get redirected through that getter/setter.

The syntax should also be as simple as possible (in C#, it's just { get; set; }, in Scala it's even simpler).

3. Simple syntax, or even completely automated, generation of
addPropertyListener or addFooChangeListener and associated methods
including firing these listeners when the setter is called.

I would place this one out of scope. I actually have an upcoming blog post on how I implemented what I think is an innovative databinding mechanism that comes close to emulating notification properties but without the heavy machinery required by PropertyChangeSupport and PropertyChangeListener.

 

4. Library or language feature to let you bind any two properties
together (one changes when the other changes, and if you want, vice
versa too).

That would be nice but probably out of scope as well. I think it's safer to put this coupling in a middle entity rather than coupling properties together anyway (n+m versus n*m).

--
Cédric

[Cédric Beust ♔]

It's amazing how many times I read "it's just syntactical sugar" as if this should put an end to the argument.

C is syntactical sugar around assembly language. Most of the time, languages are nothing but syntactical sugar over older languages.

The debate is a bit more complex than that. The question you should ask yourself is: "Is this syntactical sugar making it easier to write code in that language?".

I think that most of syntactical sugar additions tend to add complexity instead of decreasing it, but in the case of properties, I think the gains outweigh the drawbacks (can't really think of any, to be honest).

Anyway, I don't want this to drop back down to nitpicking over what is complex versus what is simple, and at the end of the day, what features you'd like to see added to Java is very subjective. However, I do hope that we stop hearing "it's just syntactical sugar", because this doesn't really help moving the discussion forward.

-- 

Cédric

On Fri, Sep 17, 2010 at 8:42 PM, Miroslav Pokorny <miroslav...@gmail.com> wrote:

Properties are in the end syntactical sugar, they dont add any real behaviour differences on top of a getter/setter. Why does it even matter, when with most modern IDEs, writing there are minimal keystrokes counts to type in a getter or setter. If one does the right and makes all their objects immutable, setters are gone. If builder setters are named property() and getters the same the keystrokes are almost identical... So why all the fuss ?

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Cédric

[Miroslav Pokorny]

Firstly I said syntactical sugar as an argument against only properties. But really is scala so much better because of "xxx.property" as opposed to "xxx.property()". On the other hand closures are actually a bit more expressive with something new. Sure maybe underneath theres a lot of synthesized stuff to make closures work on the JVM, but its a bit more than a lousy getter/setter reading/writing from a field. Its more interesting when people give real reasons rather than something like "simple properties" in their discussions of how much better Scala  is vs Java.

[Russel Winder]

On Fri, 2010-09-17 at 20:53 -0700, Cédric Beust ♔ wrote:
[ . . . ]

>
> The debate is a bit more complex than that. The question you should
> ask yourself is: "Is this syntactical sugar making it easier to write
> code in that language?".

gs/write/read/p

Reading code is far, far more important than writing it.

Perhaps we should redefine the acronym WORA to be "write once, read
anytime" and use it as a mantra for source code development? (Except
that Sun, now Oracle, probably has a copyright, trademark or patent on
WORA.)

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Kevin Wright]

Every summary I've seen for a project converted from Java to Scala reports, at minimum, a 1 : 3 reduction in LOC.

If this isn't from making invisible / automating trivial detail (as per your definition of higher level) then where's all the code going?

It can't *all* be in the semicolons!

> ...
>
> read more »

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

+100,  I couldn't agree more

[Ricky Clarkson]

I can think of cases like yours for every language.  Let's do Java (though not as well as Java Puzzlers does):

List<T> can't deal with List<int>.

for (String name: names) doesn't compile if names is a Iterator, not an Iterable.  (What's an irritable anyway?!)

final members assigned to a non-null value can be observed to be null.

To explain your examples.. note that you don't need a val/var in a lambda either, i.e., (x => x + 2) rather than (val x => x + 2).  The extra 'val' would be pointless and confusing.  Perhaps at first glance it would seem like within a for-comprehension the val would not be pointless.  But it would be val every time, as vars are meaningless in that context, so it would only help those unfamiliar with the syntax.

C#'s LINQ has a contextual keyword, let, for that case.

I think the tension is caused by mutable variables.  If Scala didn't have them, we wouldn't need val/var ever, we'd just do x = 5; like in Haskell and Erlang.

The yield case could be altered but you'd just be introducing more apparently arbitrary rules.  E.g., if for (x <- 1 to 5) { yield x * 2 } were allowed, what would happen with:

for (x <- 1 to 5) { if (x < 2) yield x * 2 else println(x * 3) }

The method calls that yield translates to are very different to the ones that code without yield (my else case) translates to, so there would be another rule; you can't use yield in some branches and not in others.  I think this would be worse than the present situation, allowing for (..) yield expression, but not for (..) { yield expression }.

I should note that you can't introduce {}s into random parts of LINQ expressions either, so this is certainly not Scala-specific.  You also can't write, in Java: if (foo) bar(); { else baz(); }.

Swings and roundabouts.  Again, there's tension caused by something underlying, the difference between pure and side-effecting code.  If as in Haskell Scala had no side effects there would be no need for the yield keyword.

As for being disingenuous, I don't think so.  Commodo parco ad hominem.

2010/9/17 Cédric Beust ♔ <ced...@beust.com>

[Steel City Phantom]

>gs/write/read/p

>Reading code is far, far more important than writing it.

>Perhaps we should redefine the acronym WORA to be "write once, read
>anytime" and use it as a mantra for source code development?  (Except
>that Sun, now Oracle, probably has a copyright, trademark or patent on
>WORA.)

wow, you really think its the languages fault you can't read old code?  one of the best coders i have ever met was a perl guy.  perl is notorious for being hard to read but you opened one of his scripts and it read like a really good spy novel.  its not the language that makes code hard to read, its the moron that wrote it.  

[Kevin Wright]

Do you say this whenever someone struggles to read your code?  Or do you believe in making your own code readable, and respect a language that helps you to do so?

 

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Steel City Phantom]

>Do you say this whenever someone struggles to read your code?  Or do you believe 

>in making your own code readable, and respect a language that helps you to do so?

absolutely i do.  i have zero problem admitting i have put out some really crappy code in my day.  but its not the languages fault that its crap, its mine.  part of the project that i have been doing for 8 years now is to go back and refresh parts of the system, sort of a nonstop ever going upgrade.  ive opened up libraries that i wrote 6 years ago and went WTF was i thinking?  again, it wasn't java's fault it was crappy code, it was mine.

[Reinier Zwitserloot]

On Sep 18, 5:42 am, Cédric Beust ♔ <ced...@beust.com> wrote:
>
> I think Lombok is a non-starter for a lot of organizations just because it's
> basically its own compiler.
>

No it isn't. It's probably a nonstarter if you use IDEs other than
Eclipse and NetBeans, sure, but, "its own compiler"? How so? The
language grammar rules do not change.

> The longer version:
>
> I want to be able to write "a.name = foo" and not have to worry about
> implementing a getter and a setter until the day where I actually need one.
> When I do, I just implement it and all clients automatically get redirected
> through that getter/setter.

I'm not sure why you find this so important. Why is "a.name = foo" so
much nicer than "a.setName(foo)"? Doesn't this entire line of arguing
boil down to: I get annoyed having to manually write "getX" and "setX"
methods? In which case, sure, but if solving that problem makes one a
higher level than java, then java+lombok is higher level, I guess. I'm
not sure thats a particularly convenient definitoin for "higher level
language" - then just about any feature of any kind means "higher
level". We'd need a billion levels.

> I would place this one out of scope.

[That was about the term "property" including the idea of change
listeners]

Why? GUI libraries suck without such a feature. Its quite marvelous
for any type of MVC design, really.

[Reinier Zwitserloot]

A 1 : 3 reduction in LOC? Don't make preposterous claims.

1 : 3 rates is what happens when you rewrite a project, from scratch,
now knowing exactly what you've learned. That's obviously not a fair
comparison.

In my own experience, Scala code tends to be about ~85% to ~90% of the
lines that java source code is. But LOC is an extremely flawed measure
of code complexity, so I'm not sure this is a useful construct.

The answer to your question is much, much simpler: Your 1 : 3 rate is
bullpuckey.

On Sep 18, 9:54 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> Every summary I've seen for a project converted from Java to Scala reports,
> at minimum, a 1 : 3 reduction in LOC.
>
> If this isn't from making invisible / automating trivial detail (as per your
> definition of higher level) then where's all the code going?
> It can't *all* be in the semicolons!
>

> >http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the....
> > ..

> ...
>
> read more »

[Reinier Zwitserloot]

This observation is irrelevant unless you meant that choice of
language has absolutely no bearing on the likelyhood that your code
ends up readable, which I find hard to swallow.

[Steel City Phantom]

> The longer version:
>
> I want to be able to write "a.name = foo" and not have to worry about
> implementing a getter and a setter until the day where I actually need one.
> When I do, I just implement it and all clients automatically get redirected
> through that getter/setter.

you can implement that today in java.  its very easy to do so as well, heres how

public class haha {

  public String name;

}

there, now you can do your a.name = foo.  not very hard.  now on your refractoring issue, do you REALLY want a language to do your refractoring for you?  i certainly don't.  i think this comes down to be VERY careful what you wish for, you might just get it.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Kevin Wright]

On 18 September 2010 09:22, Reinier Zwitserloot <rein...@gmail.com> wrote:

I'm not sure why you find this so important. Why is "a.name = foo" so
much nicer than "a.setName(foo)"? Doesn't this entire line of arguing
boil down to: I get annoyed having to manually write "getX" and "setX"
methods?

Speaking personally, no, I get annoyed having to manually *read* them.  The first form really is much easier.

 

In which case, sure, but if solving that problem makes one a
higher level than java, then java+lombok is higher level, I guess.

Of course it is, it removes the manual task of maintaining accessors, constructors, and equality/hashcode methods.

Thus making a trivial detail invisible/automated.

 

I'm not sure thats a particularly convenient definitoin for "higher level
language"

It's your own definition :)

 

then just about any feature of any kind means "higher
level". We'd need a billion levels.

I tend to see level as existing on a continuum, so there are no distinct levels.

 

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Steel City Phantom]

>This observation is irrelevant unless you meant that choice of
>language has absolutely no bearing on the likelyhood that your code
> ends up readable, which I find hard to swallow.

thats exactly what im saying.  crappy scala code is just as hard to read as crappy java code as is crappy c# code, as is crappy c++ code.  crappy code is simply crappy code.  the language its written in  is irrelevant.

[Kevin Wright]

The client has a requirement that we must be able to sort haha instances based on their surnames.

Now update that definition so that `a.name` is a concatenation of `a.firstName` and `a.lastName`, I want to be able to continue using it as `a.name` though.

[Steel City Phantom]

>The client has a requirement that we must be able to sort haha instances based on their surnames.

>Now update that definition so that `a.name` is a concatenation of `a.firstName` and `a.lastName`, I want >to be able to continue using it as `a.name` though.

ok, you got that one.  but whats the difference between

public class haha{

 public String firstname;

 public String lastname;

 public String name;

public String getName(){

name = firstname + lastname;

return name

}

and

public class haha{

 public property firstname;

 public property lastname;

 public property name = firstname + lastname;

}

maybe im just naive but i don't see any real difference between the two. sure number of lines decreases but beyond that, whats the difference?

[Kevin Wright]

Using the first form you'd have:

a.firstName

a.lastName

a.getName()

You've complicated matters by now having two styles for accessing properties, it also has the issue that someone could still access `name` instead of `getName()`

The historic solution in Java is to make all fields private and add boilerplate:

a.getFirstName()

a.getLastName()

a.getName()

The better solution is to make the object immutable, using final values:

public class Haha{

  public final String firstName;

  public final String lastName;

  public final String name;

 

  public Haha(final String firstName, final String lastName) {

    this.firstName = firstName;

    this.lastName = lastName;

    this.name = firstName + " " + lastName;

  }

}

It's okay to pre-calculate name here, because firstName and lastName can never change (that's what immutable means...)

and If I want to change a value, I have to copy the object:

Haha haha = new Haha(oldHaha.firstName, newLastName)

Or I could implement a `withFirstName()` method inside Haha that handles this logic for you - returning a new instance.

This is the same approach that Scala takes, but with Scala all the construction and copy logic is built in:

case class Haha(firstName : String, lastName : String) {

  val name = firstName + " " + lastName

}

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

On 18 September 2010 10:01, Kevin Wright <kev.lee...@gmail.com> wrote:

This is the same approach that Scala takes, but with Scala all the construction and copy logic is built in:

case class Haha(firstName : String, lastName : String) {

  val name = firstName + " " + lastName

}

I can actually go a bit further here:

  trait Named {

    def name : String    // it's a def, so could be implemented by a method...

  }  

  case class Haha(firstName : String, lastName : String) extends Named {

    val name = firstName + " " + lastName    // ... but can also implemented by a val

  }

 

This is the essence of the uniform access principle.

[Steel City Phantom]

maybe im just becoming that old grumpy c++ coder in the corner cubicle of every company ive ever worked for that believes his language is the bomb and nothing else will do.  kevin, i personally prefer the first immutable example you gave.  maybe its because ive been doing it so long it just comes naturally to me to do it that way.    i like the boilerplate code.  i like seeing all the pieces and knowing for certain what they are doing.  to have a language tell me, trust me, i got this.  will drive me out of my mind.  i don't want to trust you, i wanna see it.

i do want to get to know scala more. i think of all the next generation languages that have come out in the past few years, scala is the most promising.  when they slow down the release cycle to one release every year or two i will be VERY happy about it.  the next side project i get i want to write in scala simply to see what all the fuss is about.  but right now, i understand what your saying, i just don't get the difference between the two.  

ive never been a person to change just for the sake of changing.  i better have a damn good reason to change.  hell, this coming from a guy that still uses windows 2000 advanced server on all his home servers and FreeBSD 4 on all his company production servers.  why change what works, LOL

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Viktor Klang]

On Sat, Sep 18, 2010 at 10:25 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:

A 1 : 3 reduction in LOC? Don't make preposterous claims.

1 : 3 rates is what happens when you rewrite a project, from scratch,
now knowing exactly what you've learned. That's obviously not a fair
comparison.

In my own experience, Scala code tends to be about ~85% to ~90% of the
lines that java source code is. But LOC is an extremely flawed measure
of code complexity, so I'm not sure this is a useful construct.

What is the basis of this claim, I want examples.
 

The answer to your question is much, much simpler: Your 1 : 3 rate is
bullpuckey.

Are you honestly fighting unsubstantiated claims with unsubstantiated claims, why waste your time?


There's too much opinions and too little facts in this thread, which makes it for some quite sad reading.
I'm going to stop read the JavaPosse ML if the level of reasoning isn't improved.

> ...
>
> read more »

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Viktor Klang,
Code Connoisseur
Work:   www.akkasource.com
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

[Russel Winder]

On Sat, 2010-09-18 at 11:46 +0200, Viktor Klang wrote:
[ . . . ]

> There's too much opinions and too little facts in this thread, which
> makes it for some quite sad reading.
> I'm going to stop read the JavaPosse ML if the level of reasoning
> isn't improved.

Here, here. Made up number do not turn into facts simply by repetition.

Opinion has its place, and can be interesting, but not when purveyed as
supposedly statistically based fact.

[Kevin Wright]

It's difficult to find give hard evidence here, but not because it doesn't exist.

30% reduction seems to be the most quoted number when comparing idiomatic Scala to idiomatic Java, and this definitely matches my own experience.

So where does the figure come from?

Presentations mostly, by figures such as David Pollak, Bill Venners, Martin Odersky and Miles Sabin, all of whom have experience of working directly with large companies that have made the conversion in large scale real-life commercial projects.

and therein lies the problem... these same companies are (quite understandably) also not going to release their proprietary code for analysis by a third party.

For now, I can only hope we'll see a suitably large open-source project make the same conversion, then we'll have some hard numbers freely available for anyone to compare.

In the meantime, I have to ask myself "Do I trust that Martin is honest and professional enough to quoting genuine figures and not just making them up?".  Ultimately, he has nothing to gain by doing so, and an entire reputation to lose if he's been lying and the statistics are later shown to be "pure bullpuckey".

So do I wish I had harder evidence to cite?  Of course I do...

I the meantime, do I instead have utmost confidence in the numbers that I am seeing quoted from "official" sources?  Absolutely!

[Reinier Zwitserloot]

On Sep 18, 10:31 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
>
> Speaking personally, no, I get annoyed having to manually *read* them.  The
> first form really is much easier.
>

Not to me.

>
> Of course it is, it removes the manual task of maintaining accessors,
> constructors, and equality/hashcode methods.
> Thus making a trivial detail invisible/automated.
>

Not at all invisible. In fact, what lombok generates is extremely
visible. It shows up in your eclipse outline view, for example.

> > I'm not sure thats a particularly convenient definitoin for "higher level
> > language"
>
> It's your own definition :)
>

No it isn't. Reread my post. The smiley doesn't excuse you from making
silly statements that are clearly false.

[Ricky Clarkson]

1 : 3 is quite conservative.  1 : 5 is more realistic.  You only need to look at your own examples of Java+Lombok to appreciate that case classes make a massive LOC difference.

Type inference ends up removing a few imports per file, too, as you don't need to import a type if all you would use it for is to declare a variable.

Importing n types from 1 package uses 1 line in Scala, compared to n lines in Java.  import java.util.{ArrayList, List, Map, HashMap}

The lack of checked exceptions also makes a difference to LOC.

Lest I be named disingenuous, I should point out that for loops often take more lines in Scala.

> ...
>
> read more »

[Kevin Wright]

Just to clarify, my point was that Lombok and Scala's case classes make the *implementation* of accessors and equality methods invisible, not the *presence* of these characteristics.

I must also hold you to your own definition, as we're not even discussing the same thing if a moving target is involved!

  'A useful definition for "higher level" is that it makes invisible / automated whatever's trivial detail.'

In this case, it's certainly not trivial that an object can have properties, and be tested for equality.

But it *is* trivial exactly how such features are implemented.

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

You have "utmost confidence" in the numbers? See, saying things like
that makes me discount your personal experience as irrelevant, because
it must be very flawed. How can you have utmost confidence in a
secret, one-sided, clearly non-scientific comparison done by people
who are _extremely_ biased in favour of scala?

This is no insult to Bill Venners and Martin Odersky. Far from it,
though I am disappointed they even try to quote such numbers with a
straight face.

Let me try to teach you about why scientists take double blind studies
seriously, and why you should absolutely NOT have "utmost confidence"
in that 30% number quoted by Bill and Martin.

Psychology has (scientifically!) proven that it is human nature to
emphasize results that confirm our beliefs, and disregard, excuse, or
simply fail to notice results that don't. This isn't malice, spite, or
willful twisting of facts, it's human nature - and generally a human
is not even aware they are doing it. That's why proper scientific
study is so obsessed with double blind studies. A good scientist is
aware that he can't even trust his own judgements if there was any
chance that personal bias leaked in. It's immaterial if he is a
paragon of honesty. It's a largely unconscious effect.

So let's look at what it would take to make a reasonable real-world
claim that scala helped reduce LOC (I'm skipping, for now, the notion
that equating LOC to complexity, or readability, or maintainability,
is a bad idea). Here are some factors that will clearly influence the
end result to such an extent that any statistics derived from the
experiment are utterly useless. How can I be sure Bill and Martin have
ensured none of these affected the end result? I'm absolutely positive
they haven't. If they did, they'd have written many papers.

* The scala version was a rewrite of a java version, therefore the
scala version got the benefit of experience. Comparing the old java
code to the brand new scala version is a meaningless apples to oranges
comparison. Could be fixed by having two teams BOTH rewrite the same
thing, or by writing something from scratch.

* The programmers that worked on the scala code just got educated in
programming by such paragons as Bill Venners and Martin Odersky. If
they HAVENT become better programmers as a result of that, that'd be a
bit ironic, no?

* Standard experiment bias: In medical studies, the constant care and
attention of doctors is all by itself responsible for measurable
improvement. They eliminate it by using placebos, while the attending
staff has no idea who is getting the placebo and who isn't. A good
experiment even takes great pains to ensure the placebo and the real
medicine are not easily distinguished by smell, texture, or colour. A
similar thing may well be occurring here: The mere fact that
programmers get to play with a new language and 2 of the foremost
promoters of it are closely watching them do it is undoubtedly going
to affect their drive and dedication, which is going to make a
gigantic difference in code quality, which in turn will doubtlessly be
measurable in LOC.

* Libraries and knowledge changes over time. The java code is perhaps
the result of 10 years of coding, switching libraries, refactoring
bits here and there, sneaking some crappy workarounds in to meet a
deadline, and filled with domain knowledge built up over years and
years of bug reports. The scala code has been freshly written against
a single set of libraries, no deadlines, and no bug reports, with
state of the art knowledge about good coding practice.

* The programmers are now older and more experienced.

* The programmers working in scala are more passionate about
programming and hence likely much better at it, than the people who
decided not to spend some time meeting Bill and co. Or, at a somewhat
larger scale, the corporations that are switching to scala now have a
programming team that is measurably different in sensibilities than
your average corporation, and this difference has an effect on the pro/
con analysis between java and scala. i.e. the result of one coding
team may not be a good yardstick for what some other coding team is
going to do.

* Something as simple as coding style that's been changed. Perhaps the
switch to scala was also used to switch from open-brace-on-next-line
style to open-brace-follows-condition style. That's a 20% reduction on
the spot, which is of course meaningless!


The list goes on, of course. Even failing to handle one item on that
list is plenty distraction to make the end result meaningless.


NB: Note that if some foss project DID switch from java to scala,
you'd still have absolutely nothing to go on, for all the reasons
stated in the above list!

On Sep 18, 12:14 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> It's difficult to find give hard evidence here, but not because it doesn't
> exist.
> 30% reduction seems to be the most quoted number when comparing idiomatic
> Scala to idiomatic Java, and this definitely matches my own experience.
>
> So where does the figure come from?
> Presentations mostly, by figures such as David Pollak, Bill Venners, Martin
> Odersky and Miles Sabin, all of whom have experience of working directly
> with large companies that have made the conversion in large scale real-life
> commercial projects.
>
> and therein lies the problem... these same companies are (quite
> understandably) also not going to release their proprietary code for
> analysis by a third party.
> For now, I can only hope we'll see a suitably large open-source project make
> the same conversion, then we'll have some hard numbers freely available for
> anyone to compare.
>
> In the meantime, I have to ask myself "Do I trust that Martin is honest and
> professional enough to quoting genuine figures and not just making them
> up?".  Ultimately, he has nothing to gain by doing so, and an entire
> reputation to lose if he's been lying and the statistics are later shown to
> be "pure bullpuckey".
>
> So do I wish I had harder evidence to cite?  Of course I do...
> I the meantime, do I instead have utmost confidence in the numbers that I am
> seeing quoted from "official" sources?  Absolutely!
>

> On 18 September 2010 10:46, Viktor Klang <viktor.kl...@gmail.com> wrote:

> ...
>
> read more »

[Kevin Wright]

Which brings us full circle, back to the claim that Scala is more programmer-oriented than Java!

As a programmer, that list would motivate me to work for a company the uses Scala

As an employer, it would motivate me to hire Scala developers

> ...
>
> read more »

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

On Sat, Sep 18, 2010 at 1:30 AM, Steel City Phantom <scph...@gmail.com> wrote:

you can implement that today in java.  its very easy to do so as well, heres how

public class haha {

  public String name;

}

there, now you can do your a.name = foo.  not very hard.

Please reread my post more carefully. If one day you decide to add a setter, clients of your code who wrote "a.name=foo" won't go through that setter.

--
Cédric

[Cédric Beust ♔]

On Sat, Sep 18, 2010 at 2:46 AM, Viktor Klang <viktor...@gmail.com> wrote:

I'm going to stop read the JavaPosse ML if the level of reasoning isn't improved.

I think just skipping all the discussions that compare Java to Scala should bring the signal back up. 

Language zealots have that effect on discussions :-(

--
Cédric

[Graham Allan]

If anyone was in any doubt that the LOC metric viewed in isolation is
meaningless, I'd nominate this example as proof.

Not that I'm taking either side in the Java/Scala debate, but the last time I
had to manually add, or edit an import declaration, or read through the list
of imports, was about four years ago when I started using an IDE.

For me now, the imports in a source file practically don't exist. Comparing LOC
could only make sense when the import declarations are discounted from both
sets of code*.

So if there is to be any meaningful discussion based on LOC, the count has to
be more sophisticated than "Source.java contains x lines, Source.scala
contains y.". Unfortunately this seems to be the kind of thing that can't be
discovered when studies aren't published :-(

Kind regards,
Graham

* This is assuming Scala tools can handle imports as well as Java tools: I
don't know if they can or not.

> From: Ricky Clarkson <ricky.c...@gmail.com>
>
> To: java...@googlegroups.com

[Tor Norbye]

Right. Just to expand a bit further on this: A field plus a getter and
setter isn't -really- what we mean when we say we want -proper-
property support in the language. Think of a GUI component instead,
such as as a slider. I want -client- code to be able to do this:

slider.min = 0;
slider.max = 100;
slider.value = 50;
....
// and to read slider: just reference slider.value
textBox.content = bind Integer.toString(slider.value);

This can't just be a public field because things need to be organized
such that when you set the property the UI representation of the
component updates itself.

With old JavaBeans this was done with special code in the setters
which would fire property change listeners (that the view listeners
listen for). With JavaFX properties are directly supported in the
language so it's using various bind-machinery to handle this.

The point is that for real properties you can't just use a field; in
Java you need to use proper setters -- which means you don't get the
nice uniform access shown above. In languages that support properties
this works nicely.

-- Tor

On Sep 18, 7:15 am, Cédric Beust ♔ <ced...@beust.com> wrote:

[Kevin Wright]

I have to agree with this, counting preamble at the top of a file is totally relevant when comparing two implementations of an algorithm.

But there is a place for metrics, including NCSS and cyclomatic complexity, and there are times when *something* needs to be measured in comparing approaches.

Even if you disagree with the choice of metrics, I think it's hard to argue that tools like Sonar are without merit

It's also important to take an agile approach and keep looking back once in a while to see if the chosen measurements are turning out to be useful.

* Sonar: http://www.sonarsource.org/

Demo site: http://nemo.sonarsource.org/

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

On Sat, Sep 18, 2010 at 10:52 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

I have to agree with this, counting preamble at the top of a file is totally relevant when comparing two implementations of an algorithm.

You probably meant "irrelevant" above?

I agree with Tor that imports are all but invisible in JVM programming these days.

--
Cédric

[Kevin Wright]

*faceslap*

Well corrected that man.

2010/9/18 Cédric Beust ♔ <ced...@beust.com>

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

Indeed, Tor. Properties doesn't just mean "nice sugar so I can make x
= 0 really mean setX(0)". It also means seamless support for
propagating changes, including the ability to bind two properties
together.

I find JavaFX's solution particularly elegant, and when we get around
to adding property support to lombok, we're likely going to pattern it
around that and not the beans jsr.

[Ricky Clarkson]

I agree that the metric isn't very good alone.  However, I'm sure having a block of crap at the top of every file that you ignore (but tools read) isn't optimal.  Scala goes a little way to making those less necessary to fold, but not all the way.

[Kevin Wright]

As an representation of quantities that interact and change over time, the properties/observers/events model is far from being the only game in town.

Anyone who's run into issues with the event dispatch thread can attest to weaknesses in the approach.

There's a brilliant (if lengthy) presentation on the topic by Rich Hickey (Clojure author) here: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

It's also worth checking out the recent "deprecating the observer pattern" here: http://lambda-the-ultimate.org/node/4028

Or just run a search on "Functional Reactive Programming"

The basic idea is that something like window.height isn't a `property` that you can register events on, and have notifications pushed whenever it changes.

Instead, "height" is just a stream of integers, that can be passed around like any other variable.

You can iterate over this stream, and the iteration blocks until a new value appears.

The best part of this approach is that streams can be composed and filtered, so you could take window.height, and subtract splitbar.position to yield a new stream

(operator overloading and closures help here)

The result, also a stream, can then be assigned to the height of a panel in a window layout.

As designs go, it's kinda elegant.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Miroslav Pokorny]

On Sun, Sep 19, 2010 at 3:52 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

I have to agree with this, counting preamble at the top of a file is totally relevant when comparing two implementations of an algorithm.

Why would anyone count or care about imports. Most IDEs fold or hide them and adding them is almost always a key combo away. Counting this as a major feature seems quite desparate, surely theres something more worthwhile or impressive than this.

[Kevin Wright]

Read on, it was a typo...  Was meant to be "irrelevant"

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Josh Berry]

Amusingly, import order is actually a matter of contention by many of my coworkers right now. :)  So, some folks actually do care.  (Essentially, the "default" order of intellij and eclipse cause constant "conflicts" in source control.)

I would liken this with the tabs versus spaces argument, though.  In general, it shouldn't matter at all.  

[Reinier Zwitserloot]

Huh? What does the EDT have to do with property binding?

On Sep 18, 11:21 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> The best part of this approach is that streams can be composed and filtered,
> so you could take window.height, and subtract splitbar.position to yield a
> new stream
> (operator overloading and closures help here)
> The result, also a stream, can then be assigned to the height of a panel in
> a window layout.

Sounds like needless complication to me. If properties with binding
had existed and I needed this, you can bind with a filter, and you can
choose whether it should be one-way (changing the window size changes
the panel) or two-way (changing the panel's height also scales up the
entire window). Yes, closure support would be handy to make the filter
API nicer, but I don't see how treating the property as a blocking
iterator helps. In fact, it hurts, a lot. It means you need a
bajillion threads. This isn't a big deal these days, you can have
thousands on a single system, but it does gulp down quite a bit of
memory to maintain all those stacks. It would look something like
this:

window.height.addOnChange(#(h) {
panel.height = h / 3;
}

looks elegant, easy to read, easy to maintain, and flexible to me!

With your stream example, it would have to look like this (I'm sure
I'm screwing this up, it can't be this obtuse!):

new Thread(#() {
for (int h : window.height.stream()) {
panel.height.push(h / 3);
}
}).start();


It also doesn't appear to solve the endless loop issue that can be a
bit complicated to avoid when specifying the properties system: If you
bind A to B and B to C, how do we ensure that changing for example A
doesn't cause an endless cascade of property updates, each continuing
the endless loop by issues new onChange calls? The usual solution is
to not propagate a new change event when a new value equals the old
value, and that works. An addition can be that if A is changed in the
middle of A itself propagating an earlier change, an exception is
thrown (because this is not going to end well).

Using an iterator is not going to make any of that any easier.

[Reinier Zwitserloot]

I usually get funny looks and stares when I argue this, but in my
opinion a good programming language _defines_ style rules. The
language spec should say what indent one should use. Don't like it?
Tough. Suck it up. The benefits of the entire community using the same
style outweigh any individual's annoyance at not being able to use
their preferred style. Same goes for something like import sorting.
Failing to follow the rules shouldn't result in compiler errors, but
definitely compiler warnings, and by the the mere existence of a spec-
level official style, all generators and IDEs and such can thus
standardize on that. When a new style war breaks out, the language
design team should take pains to release an update to the document
ASAP, and update the compiler with a minor rev to start emitting
warnings when you're using the wrong style.

Although, for certain aspects, such as enforcing exact indenting style
for i.e. blocks of code, a smarter compiler / editor can notice that
your braces are unmatched, and instead of (as is usual today) giving
you a really dumb error message in the wrong location, it can actually
look at your indents and figure out with much higher accuracy where
you omitted a brace or inserted a superfluous one, basically
understanding you 100% correctly and producing only one compiler error
that nails the problem 100% (The message would "You missed a brace
here", and the position would be in exactly the place where you should
be inserting it).

On Sep 19, 1:36 am, Josh Berry <tae...@gmail.com> wrote:
> On Sat, Sep 18, 2010 at 5:58 PM, Miroslav Pokorny <
>

> miroslav.poko...@gmail.com> wrote:

[Kevin Wright]

Behind the scenes, this is a form of dataflow concurrency, delimited continuations being the secret sauce that makes it all work.

(if you're familiar with continuations in Jetty 7, you'll have a broad idea of the technique)

So, yes, threads are involved, but not in the way you imagine.

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Graham Allan]

You're right about that, it's not optimal, and given the choice I'd opt for
less crap. But, having said that, it's so far down the list of priorities for
switching languages that it's not even worth mentioning.

Out of interest, do the Scala tools (such as the Eclipse plugin) handle
imports as seemlessly as their Java counterpart? (I swear I'm going to try
some of this stuff Real Soon Now).

Regards,
Graham

> From: Ricky Clarkson <ricky.c...@gmail.com>
>
> To: java...@googlegroups.com
>

[Kevin Wright]

Not quite as seamlessly, but both Eclipse and IntelliJ now do a reasonable job of import management.

 

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Josh Berry]

On Sun, Sep 19, 2010 at 1:43 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:

I usually get funny looks and stares when I argue this, but in my
opinion a good programming language _defines_ style rules.

Meh.  I think it is a waste of time to worry about most of the style rules.  Not to mention, style is such a nebulous term that it is borderline idiotic to really try and codify it.  Imagine if you had a style for what prose should read like.  This is what most people try to do with programming.  :)  (I saw a good analogy with Jazz the other day.  Have you ever tried to codify "good" music?)

[B Smith-Mannschott]

(not that anyone asked, but I have a few worthless thoughts on the layout side of coding standards...)

I'm all for having a standardized code style, but I have yet to see a code style or automatic formatting tool that doesn't 

make at least some of a sufficiently large and varied code base look like a$$. There are things good programmer can do with style/layout to guide the reader, which by-the-letter adherence to any one code style would make hash out of.

For Java, I hew closely to Sun's style guidelines (with 4-space indents, no tabs), but I'm not too uptight about it. I can see the advantages of BSD (braces on their own lines), particularly with complex conditionals or methods with many parameters. OTOH, overly zealous adherance to BSD style makes inner classes read badly.

For Clojure and Scheme I just do whatever emacs tells me. ;-)

For Oberon, I used hard tabs and put multiple statements together on one line if they seemed to "chunk" [1] together. No tricks with vertical alignment (unless one cared to explicitly set tab-stops) the standard font (Syntax) was proportional.

[1] http://en.wikipedia.org/wiki/Chunking_(psychology)

// ben

[Cédric Beust ♔]

I've found Java to be remarkably style impervious in the sense that I can read Java code using all kinds of different styles (different indentations, different brace placements, different namings for fields or variables, etc...) and not be bothered by it for more than a few seconds.

I can't say the same about C++ and it's probably too early to tell whether Scala has this nice quality too.

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Cédric

[Kevin Wright]

Totally, I'll just read what I'm given - or reformat in an IDE if it's *really* bad (e.g. written with a different tab size other than 4)

I'm also finding that the guideline 2 space indents in Scala is a nice visual reminder as to which language I'm working in, more than once I've found myself typing `val x = ...` in Java code!

Scala does have a bit more syntactic flexibility that Java does, but the choices available are in a similar category to bracket placement in Java (i.e. you may prefer to write in a different style to the code you're looking at, but that won't really make it unreadable).  The choice of paradigm (imperative/functional/type classes/etc.) is more likely to cause problems than the choice of syntax, but - again - this is of a similar level to encountering something like singletons or the visitor pattern for the first time.

2010/9/19 Cédric Beust ♔ <ced...@beust.com>

--

[Josh Berry]

2010/9/19 Cédric Beust ♔ <ced...@beust.com>

I've found Java to be remarkably style impervious in the sense that I can read Java code using all kinds of different styles (different indentations, different brace placements, different namings for fields or variables, etc...) and not be bothered by it for more than a few seconds.

I can't say the same about C++ and it's probably too early to tell whether Scala has this nice quality too.

I've found the biggest thing that I hate about Java nowdays is that I am forced to organize my code around what Java wants, not around how I am actually thinking about things.  I grant that you can easily abuse packages != directories, but I have found there is less value in that equality than I would have thought.

Of course, I still have dreams of someday writing a "literate" program. :)

[Kevin Wright]

You should check out ScalaTest, or Cucumber in Ruby, or Spock in Groovy.  I know there are similar frameworks in other languages - just can't remember the names right now!

For some reason, test frameworks seem to be a hotbed of innovation for all this literate DSL'y stuff

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Josh Berry]

Yeah, Specs has been the example that I've used to show people "literate specifications."  

And, I realize there are some rather enjoyable "literate" programs in Java.  James Iry's wonderful chucking example is rather fun. http://james-iry.blogspot.com/2010/08/on-removing-java-checked-exceptions-by.html

[Steel City Phantom]

I happen to like javas package system. It's simple and absolute. I
like that. That issue is actually one of my biggest complaints about
c# trying to organize code in that is a nightmare to me. To many ways
to screw up in my opinion

> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>

--
You want it fast, cheap, or right. Pick two!!

[Josh Suereth]

the val does not evaluate to (), the compiler actually adds the () after the val definition.  It's a workaround for situation where you assign to a value in a code block.   It removes the need for () at the end of an expression that does so.

(I know I'm late on this conversation).

- Josh

On Fri, Sep 17, 2010 at 12:31 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

precedence rules are catching you out here, you need the braces:

def x = { val y = 5 }

It also works just fine in compiled code

On 17 September 2010 17:19, Ricky Clarkson <ricky.c...@gmail.com> wrote:

That's an interpreter illusion; a variable declaration is not actually a value, otherwise you would be able to write:

def x = val y = 5

On Fri, Sep 17, 2010 at 4:50 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

On 17 September 2010 16:18, Reinier Zwitserloot <rein...@gmail.com> wrote:

Correction: In java, as in scala, all expressions "return" a value
(not really the right term, that. Expressions *have* a value is closer
to the mark). It's just that in scala more things are expressions.
Like "if": Expression in scala, statement in java. Not ALL things in
scala are expressions. Variable declarations aren't, for example.

Hot from the Scala REPL:

scala> val x = { val y = 32 }

x: Unit = ()

So even variable assignments evaluate to a value.

 

In any java library that isn't completely worthless, the code is
"getField()". If you get annoyed at writing out the accessor, use
lombok. Claiming that as a benefit to scala seems like you're grasping
for reasons.

It's a major benefit:

trait X {

  def property : Int

}

class Y extends X {

  val property = 32

}

When I use `property` from an object of type X, it really doesn't matter if it's implemented via a field of if it's computed.

That freedom from having to know (or care) is a simplification to me.

 

A useful definition for "higher level" is that it makes invisible /
automated whatever's trivial detail. This is a double-edged knife,
though: Whether or not a detail is trivial depends on the problem. For
example, C conveniently abstracts away the concept of stack, but in
the process of doing so, removes the ability to store stacks. The JVM
abstracts away memory management, but in the process of doing so
introduces non-determinism due to gc runs.

However, with that definition scala isn't much higher than java. There
aren't many things that you can no longer do in scala but which you
can do in java, and on the flipside, there aren't many things that are
orders of magnitude simpler in scala than java because something has
been abstracted away. Scala is more a sideways step: It's operating at
the same general level of abstraction as java, but with a different
syntax, which includes more emphasis on function objects (something
java CAN do, but not with particularly nice syntax), as well as a less
rigid syntax structure, and a general more functional outlook.

Function objects are just a tiny part of it, not only does Scala have functions that are objects, but also any arbitrary object can be made into a function.

On top of this there's pattern matching, implicits (which allow for type classes), higher-kinded types and by-name params.

Closures alone don't make a language higher level than Java, but Scala really isn't about just closures...

Just compare the implementation of a heterogenous list in both languages:

http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the-limits-of-the-java-type-system/

http://apocalisp.wordpress.com/2010/07/06/type-level-programming-in-scala-part-6a-heterogeneous-list%C2%A0basics/

 

On Sep 17, 3:28 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> I'm recently taking the position that it's impossible to state which of two
> languages is "simpler", the term is just too heavily overloaded.
>
> Just pick your definition and it's trivial to show that assembly is simpler
> than LISP, or vice-versa, but you've still achieved nothing.  If we use the
> term "higher-level" instead of "simpler", then this difficulty evaporates.
>
> Personally I feel that Scala is simpler than Java, but that statement means
> nothing without also explaining the particular definition of the term that
> matters to me.  In this case, it's two features of that language that really
> stand out, and show Scala to be the higher-level language..
>
> 1. It has constructs that closely match the way I think about problems.
> When I have to mangle the design in my head so that it matches the features
> of the target language, I perceive that as an unneccessary complication in
> the design+implementation process.
> 2. Scala has a smaller general-purpose syntax that I can use accross a wide
> range of problems, instead of a larger number special-case constructs.  For
> example:
>
> - Java has the ?: operator, but Scala has the much more general idea that
> all expressions return a value.
>
> - Java has a switch statement over numbers, enums and (soon) Strings, wheras
> Scala has pattern matching that isn't limited to any type.
>
> - Java has primitives, and operators are limited to only working with
> primitives.  Everything in Scala is an object, and operators are just
> methods.
>
> - Java has special behaviour for concatenating an object or primitive to a
> string, Scala can do this with implicit conversions - a feature that's
> useful in many more situations.
>
> - To fetch a value from an object in Java, I must first know if it's a fixed
> value or if it'll be calculated, and so use field or getField() as
> appropriate, Scala doesn't force this distinction and so it's enough to know
> I'm fetching a value, the underlying logic could even be changed in the
> future without breaking my code.
>
> The ability to work with general concepts and not have to chose exactly
> which special feature I need in a given situation... I see that as
> simplifying the task of programming.

> I could say more, but it's probably just "simpler" to point here:http://stackoverflow.com/questions/727078/whats-so-great-about-scala/...

>
> On 17 September 2010 11:30, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
>
>
> > That just sounds like equating "simple" to "less verbose".
>
> > For example, with optional () for args-less method calls, you get a
> > number of things which one might deem "simpler":
>
> >  - Less characters to type and read
> >  - The ability to not have to care about whether the doClick member is
> > a method or a field
>
> > On the other hand, you also get a few things which are decidedly more
> > complicated:
>
> >  - A stylistic choice about whether or not you add the (). Having to
> > make an irrelevant choice of any sort clearly seems like a lack of
> > simplicity to me.
> >  - The INability to tell if doClick is a field or a method. In certain
> > circumstances it matters, and having to look it up is more complicated
> > than being able to tell at a casual glance.
>
> > These are clearly conflicting requirements. Forcing you to care
> > whether doClick is a field or a method is needless complexity....
> > unless it isn't, in which case not being able to tell is needless
> > complexity. Offering the programmer the choice doesn't help, because
> > the choice in it self is needless complexity, and by existing we still
> > can't tell, given "foo.doClick", if doClick is a field or a method.
> > We'd have to rely on a programmer following the local style guidelines
> > (if, say, these state that non-fields ought to be called with parens),
> > which you can' even unit test. Now we're introducing needless
> > complexity there.
>
> > Oh, how complicated.
>
> > There's also the issue of moving complexity around to the problem
> > domain. My usual retort to those complaining about the complexity of
> > generics is simply this: Co- and Contravariance is _inherently_
> > complicated. When you have a problem where generics is required or
> > seems quite useful, then the problem has this complexity, inherently.
> > You can choose not to use generics, but then the complexity is just
> > hidden away in javadocs and a bunch of casts. You can tweak generics a
> > bit, declaration-site generics probably being the most drastic, but a
> > truly "simple" generics will never be, because co/contravariance isn't
> > simple.
>
> > So, did java become more complex when 1.5 was introduced? Yes. Does
> > this mean java 1.5 is worse than 1.4? No - in fact, it's better.
>
> > So, in certain ways, a more complex language is actually a good thing.
>
> > Hence my conclusion that all this talk about "complexity" is not going
> > to convince anybody one way or another, because its very very easy for
> > anyone reading the word "complexity" and imagine whatever situation is
> > least likely to convince them.
>
> > So, to try and mitigate this, here's where I believe scala has added
> > needless complexity:
>
> > Stylistic choice is EVERYWHERE. This is what, as I said, *I* mean by
> > DSLish features (yet another vague term that can mean just about
> > anything). Should I put () after an args-less method call? There's a
> > stylistic choice there. dots to dereference? Another stylistic choice.
> > Use operator overloading, or not, and if I do, left-associative or
> > right-associative? There's also boatloads of semantic choice in scala.
> > If I need to iterate over a map and, say, produce a list containing
> > the concatenation of each key and associated value, in java there's
> > really only two obvious ways to do it. Both involve looping, and the
> > only difference is whether I iterator over entrySet() or keySet(). In
> > scala, there's _way_ more choices. I can do a java-style loop, or I
> > can use an each construct that fills the list, or I can turn the keys
> > and the values into two sets, and then zip them up, functional style,
> > or I could use a comprehension of some sort.
>
> > Why is this bad:
>
> > Well, obviously a language can't eliminate _all_ stylistic choice. At
> > the very least you have to pick a name for your methods, and naming is
> > clearly up to you, the API author. But, scala goes _way_ too far in my
> > opinion. While it seems like a nice idea, give an API designer, and an
> > API user, the ability to write in whatever feels most natural (i.e.
> > readable, easy to maintain), that's great! Except when it isn't: By
> > introducing all these stylistic choices, you're forcing the API user
> > to pick at every stage. Sometimes, this choice is good, because the
> > benefits of picking the best option available outweigh the burden of
> > having the choice. In all other situations, though, this choice is not
> > useful at all. It makes sharing code harder (because Joe likes 'each',
> > but Jack likes 'for'). This is like spaces v. tabs: The flexibility of
> > using either really isn't helping. We'd have been better off if back
> > in the day someone put their foot down and declared some indent style
> > to be the only one compilers will accept from here on out. Deviation
> > from this one rule results in compiler warnings. I can't claim to be
> > very scientific about it, but to me it feels like Scala has gone
> > waaaay too far down the "give the programmers the flexibility" path.
> > Where the flexibility helps me make code do different things, that's
> > fantastic. Where this flexibility boils down to the exact same end
> > result, and I just have many different ways of expressing the same
> > concept, usually, it's just a bother. It's needless complication.
>
> > The python folks differentiated themselves from the Perl folks early
> > by turning Larry Wall's "There Are Many Ways To Do It" around into
> > "There Is Only One Way To Do It" and I subscribe to the theory.
> > Introducing stylistic choice needlessly is always bad. But yet again
> > there's a dichotomy here: Where stylistic choice turns from pointless
> > to useful is a moving target, there isn't a single answer to the
> > question.
>
> > Perhaps I was unclear about my comment in regards to using java
> > libraries in scala code: If you're going to write scala, then... write
> > scala. Which means you use THEIR collection APIs. If you stick with
> > java.util.List, then interopping with other scala code is going to be
> > a nightmare, and even if most scala programmers are familiar with the
> > java APIs (which is clearly an argument that can't scale: If scala
> > outgrows java in popularity, or gets even remotely close to it, how
> > can that possibly be true?), its like not following the camelcasing
> > conventions in java code. It throws people off, makes your code
> > ridiculously hard to understand. Just don't do it. There's no going
> > halfway, and there's not much point (as you said too) in trying to
> > stay up to date with both java and scala. Pick one. That's your go-to
> > language for larger projects where static typing is nice, and/or speed
> > is not unimportant. If you want to learn more languages, fantastic.
> > But don't pick java and scala. That's a silly combination, the problem
> > domains where these 2 languages shine overlap far too much.
>
> > On Sep 17, 10:42 am, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> > > Reinier,
>
> > > You want a definition of simple?  Ok, some code is more simple than some
> > > other code if it contains fewer tokens that are outside the domain.
> >  E.g.,
> > > Cobol's ADD 1 TO AGE GIVING AGE is not as simple as C's age++.  Java's
> > > SwingUtilities.invokeLater(new Runnable() { public void run() {
> > > button.doClick(); } }) is not as simple as Scala's:
> > doLater(button.doClick).
>
> > > Staying cutting edge on Scala is easier as it does not require a cutting
> > > edge runtime.
>
> > > In my opinion, for tasks for which Java is a reasonable option, so is
> > Scala,
> > > as it is typed and runs in the same environment.  I wouldn't look at
> > Groovy,
> > > JRuby or Jython for those, because they are untyped.
>
> > > Regarding writing in DSLs, pretty much all code unless
>

> ...
>
> read more »

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

Kevin Wright

mail / gtalk / msn : kev.lee...@gmail.com

pulse / skype: kev.lee.wright
twitter: @thecoda

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

Kevin Wright

mail / gtalk / msn : kev.lee...@gmail.com

pulse / skype: kev.lee.wright
twitter: @thecoda

[Reinier Zwitserloot]

You're equating english or jazz to programming? That seems, in a word,
ridiculous.

The simile would be in trying to codify what kinds of _programs_ you
could write. That would indeed be a very bad idea. Trying to codify
_how_ you write them is something programming languages do pretty much
by definition.

The work of art is what your program can do. Not what your source
looks like. Obfuscated C contest notwithstanding.

On Sep 19, 6:03 pm, Josh Berry <tae...@gmail.com> wrote:

[Reinier Zwitserloot]

I don't think he invented it. For those who have an interest in it, a
better alternative is, instead of declaring that you return "A",
instead forget A and declare that you return "RuntimeException". Then,
advise people to use:

throw sneakyThrows(new IOException());

instead of James's:

return sneakyThrows(new IOException());

The point being of course that the "sneakyThrows" method never
completes normally, so neither your "throw" nor your "return"
statement actually "runs". The code blows up with an exception before
that can happen. You do get the benefit of the compiler knowing this
too, that code won't advance beyond this line, but in a way that's
semantically closer. And you eliminate a generics parameter, that's
always useful.

On Sep 20, 1:17 am, Josh Berry <tae...@gmail.com> wrote:
> Yeah, Specs has been the example that I've used to show people "literate
> specifications."
>
> And, I realize there are some rather enjoyable "literate" programs in Java.

>  James Iry's wonderful chucking example is rather fun.http://james-iry.blogspot.com/2010/08/on-removing-java-checked-except...

> >> javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/javaposse?hl=en.
>
> > --
> > Kevin Wright
>

> > mail / gtalk / msn : kev.lee.wri...@gmail.com

> > pulse / skype: kev.lee.wright
> > twitter: @thecoda
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to java...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> > .

[Ricky Clarkson]

Reinier,

You must understand that this is subjective.  As usual, if discussed to a limit we'd just end up debating the meaning of various terms.

Programming is, yes, about making the computer do something, but beyond a very small scale one needs to be able to read existing code.  At that point the way the code is written starts to matter, and arguably that's the point at which it becomes art, as it is then an expression of intent.

Jazz played like software would be terrible though, the pianist would stop and launch a patent suit when the clarinet player made a variation upon his improvised theme.  The language is English.  The other subject is software.  The language written like the other subject would be terrible too, you'd need to jump all over the novel to get any context.

[Kevin Wright]

Not just jazz, but all music!

Functional programming is classical, web front-ends are pop, PHP is Britney Spears, Ruby is closer to Rock.

Scala was almost certainly written by Beethoven, Clojure was probably Satie

As an analogy, it has a lot of potential...

--
Kevin Wright

mail / gtalk / msn : kev.lee...@gmail.com

[Ricky Clarkson]

Perl would surely be heavy metal (almost line noise).

I'd have put Ruby in as prog rock; you either love it or wonder what's wrong with the guy's keyboard.

Java's a three-chord trick, Coq is a performing arts piece (again, you wonder what's wrong with the guy's keyboard).

[Kevin Wright]

I always imagined Coq more as coming from a string quartet.

[Miroslav Pokorny]

On Mon, Sep 20, 2010 at 8:37 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

Not just jazz, but all music!

Functional programming is classical, web front-ends are pop, PHP is Britney Spears, Ruby is closer to Rock.

Scala was almost certainly written by Beethoven, Clojure was probably Satie

As an analogy, it has a lot of potential...

That cant be right, Beethoven was German and Martin is Swiss, Ruby is JPop after all Matz is Japanese...

[Kevin Wright]

EPFL is Swiss, Martin is German...

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Amarjeet Singh]

An anything recursive is trance.

--
Amarjeet Singh
Phone: +91-98712-76661

[Josh Berry]

On Mon, Sep 20, 2010 at 2:34 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:

I don't think he invented it. For those who have an interest in it, a
better alternative is, instead of declaring that you return "A",
instead forget A and declare that you return "RuntimeException". Then,
advise people to use:

I think you misunderstood my post.  I was not intending that he invented the "sneaky" throws.  I was using that as a great example of a "literate program."   Not only does it provide the functionality that the compiler needs, but it does a very good job of presenting the subject to other coders.  Without having to rely on "compiler plugin magic happens here."

And yes, I'll stand by my comparison of English/music to programming.  You twist my point into saying that "all programs should stand as a work of art."  I don't believe that any more than I believe that "all novels are works of art."  I contend that the best of each category likely fit that bill.

To follow your definition that programming is all about "how" to write something.  Have you not considered poetry?  That is often specified down to the number of syllables allowed.   Does this make Haiku or other forms of writing less expressive?  Of course not.  Not any more than a very skilled Java programmer/writer can be expressive in Java.  (Which is why I brought up James' post.)

[Reinier Zwitserloot]

I have no idea how any of this is related to giving programmers the
ability to bicker endlessly about pointless trivialities such as tabs.
v spaces, and/or the strange notion that giving programmers the
ability to louse up their indents is more important than generating
useful and localized error messages when there are syntax errors.

On Sep 20, 3:21 pm, Josh Berry <tae...@gmail.com> wrote: