What's a good API to choose? What will be sufficient? I doubt I could
choose one where you would say "Well this properly represents java." One of
the neat things about the Scala code was that *it is using the DOM* (at
least the scala equivalent). The API is just as convoluted and strange as
the java API, only it makes use of some powerful syntax (for expressions) to
simplify using it. We use jaxb at work, and TBH Scala negates my need for
it for most small utilities.
EasyMock is perhaps the first Java API that I was truly startled by, and
allowed me to greatly simplify my testing code. To this I submit that the
scala equivalent is just that: equivalent.
IF you want me to use Java Designed APIs in scala, that's fine, but it's
also not a 100% fair comparison (by your definition). I also disagree with
the 95% of code comparison. Java tends to be just as verbose as scala for
the trivial portions of my job (Call these various busines methods and pass
the data to this other one), but the ones that matter, the ones that make or
break a feature: Those are the times when a different choice of language
can save me hours/days of coding. Having written Scala + Java apps for
production, I can speak from experience. Where are your numbers coming
from?
Perhaps a Java API and a Scala API that wraps the java equivalent? Pick the
API. Ideally I'd also like to show the expressiveness of JavaScript
compared to Java.
In response to the "the syntax is strange, and java is easier to understand"
argument, my response is that I find developers to be highly intelligent and
adaptable people. The syntax becomes less foreign in time, to the point
where you can figure out what is going on simply by looking at the code.
We've recently brought a team up to speed on advanced JavaScript, and there
aren't many who can't look at the code and reason what's going on. The same
with Drools Rule language.
If you can't trust your team with a powerful language, how can you trust
them with a not-so-powerful language? People commit attrocities with any
number of tools. It's a problem with the person, not the language.
Anyway, I realize that this is not the best forum for this discussion
perhaps. I hope you all realize that I do like the Java language.
Otherwise, why would I listen to the podcast? I'm just iterating my belief
that the JVM (and its convienient way of distributing cross-platform
libraries) is the true gem of Java. I'm willing to continue the coding
challenge, but from the responses, I think perhaps I'll refrain from
expressing my opinions in the future.
-Josh
On Thu, May 7, 2009 at 3:47 PM, Reinier Zwitserloot <reini...@gmail.com>wrote:
>
> On May 7, 2:23 pm, Josh Suereth <joshua.suer...@gmail.com> wrote:
> > Regardless of what API was chosen, the resulting for-expression is much
> > easier to read and has higher SNR.
>
> If API doesn't matter to show off how much scala is better, then why
> did you pick an API that throws off the entire experiment? I presume
> your attempt in these posts is either to change people's opinion in
> regards to the need for more elegant structures in java, OR to change
> people's inclination towards giving scala a try.
>
> You failed.
>
> By using the DOM API, every java programmer who reads it goes: Well,
> duh, DOM sucks. I know that. This doesn't convince me in the
> slightest.
>
>
> If what you say is true, back up your words, and use real, java-
> designed, APIs, on both sides. DOM isn't a real java API - DOM is
> language agnostic, and a DOM implementation needs to follow many
> rules, even if they are awkward and result in confusing and wordy end-
> user code in the target language. That's the strength, and mostly the
> disadvantage, of the DOM API. You can NOT use it to prove a thing
> about java. You can talk all you want, but without a single actual
> example that can be used to compare java and scala properly, I stick
> to my point: you're all vastly exaggerating, and java is no more than
> ~20 to 30% more wordy in 95% of the code you'd want to write out
> there, presuming sufficiently skilled java and scala programmers
> (remember that scala has new car smell bias: Scala programmers tend to
> be both programming experts and programming hobbyists, and took some
> effort to really learn the language properly. Therefore, you cannot
> pick a random sample of java and a random sample of scala and compare
> them; doing this proves only that all new languages have a grace
> period in the beginning where code quality is artificially inflated.
> This is true; I'm not sure anyone here needs proof of this concept).
>
>
>
> > [Swing]
>
> Nice, pick another API where we've all already agreed that java is a
> bad fit. That's why JavaFX exists, which is a great fit. Better than
> scala, even.
>
> > [Java is the assembly language of the JVM]
>
> No, it isn't. You can't throw checked exceptions without declaring
> them, you can't create invokedynamic, and there are a host of other
> perfectly valid byte code concepts which you can't write in java.
> Also, many JVM-based languages out there have primitives for
> everything you could possibly do in java. If you program without using
> much of the scala libraries in scala, instead using the java
> libraries, your class files will be very similar.
>
> If the java developer team, or those supporting it, think that java
> gets some sort of free pass because it's the C of the JVM world,
> they're Getting It Wrong. Java, the language, needs to stand on its
> own. If scala, fan, clojure, or groovy beats java consistently and
> with a large margin (on average), in all areas where one might want to
> use the JVM and taking into account all the circumstances (such as
> editors, debuggers, tools, documentation, yadayada), then java should
> die and we should all switch.
>
> > [Use the right tool for the job]
>
> Sort of. To get familiar with a language syntax, you need anywhere
> from 2 weeks to 3 months depending on how novel the language is and
> how experienced you are. To get familiar with the libraries (and so
> far, most JVM languages bring along their own library, including
> clojure, scala, and fan, and bucking this trend and using the java
> core libs just produces a bastard child that is ugly and
> unmaintainable), you need a year. To really become a 'guru' in a
> language, that takes many years, and a dedication to keeping up to
> date, which includes using it, often.
>
> (Note: Some languages are so similar that you can pick one up very
> quickly if you know the other. However, these languages almost always
> overlap in function so much that knowing both is useless; the amount
> of jobs out there where one language is a good fit but the other
> isn't, is nearly zero. Therefore, it's not fair to claim: "But
> learning python if you already know ruby is so easy!" - That's true,
> but the very aspect that makes that easy also makes knowing both
> virtually pointless. A fair comparison is learning clojure when you
> know java, or erlang if you know python, for example).
>
> Considering the phenomenal cost of maintaining knowledge of 2 or more
> languages, it is perfectly reasonable to consider every problem a nail
> for your one hammer. Bashing a screw into the wall with a hammer is
> just easier all around if a screwdriver takes 5 years to learn how to
> operate.
>
> You should still endeavour to learn new languages, for a few reasons:
>
> 1) It usually improves your understanding of your 'main' programming
> language, and
>
> 2) If you stubbornly stick to your hammer no matter what, eventually
> the world just moves on and you're stuck holding the bag. If the time
> is ripe to switch horses, it helps if you at least have a rough
> understanding of what's out there.
>
> However, both of those reasons are for personal development, and
> getting either benefit does not require you to hit guru level.
>
> > [More interviews on Fan, Clojure, Scala, Groovy, JRuby]
>
> Amen!
>
> On May 7, 2:23 pm, Josh Suereth <joshua.suer...@gmail.com> wrote:
> > No matter what API you use in java,
> > building up a list of items from some other datastructure usually
> requires
> > insantiating the list, then iterating over all elements, testing various
> > conditions, then placing them in the list. Finally, you return the list.
> > Using for expressions, you have a lot less noise to accomplish the same
> task
> > without losing readability.
> >
> > Should I also show examples of:
> >
> > 1) Parsing text files
> > 2) Resource Management
> > 3) Tree/Model Manipulation
> > 4) Declaring Class Hierarchies
> >
> > Don't get me wrong. I like the Java language. However, I see its days
> as
> > the general purpose language of choice being numbered. I actually like
> the
> > Swing framework for being amazingly powerful. I had to write a
> > high-performance graphing library (live interactions/updates) and the
> Swing
> > API really saved us a few times by allowing us to be crazy flexible.
> > However, the other 80% of the time, I wish there was some simpler way of
> > defining my app (or at least, better databinding). I don't see Java
> > disappearing, I see java being the "if you want high-performance on the
> JVM,
> > you write it in java" vs. "if you need to get this done quickly and its
> > execution time isn't critical" being other languages.
> >
> > If you look at what is being done on top of the JVM nowadays, it's pretty
> > phenomenal. I really think this is crucial to JVM success. Not every
> > language is suited to every task. You should choose languages
> > appropriately. JavaFX appears to be a really great language for UI
> > development. As it speaks to "native java", you could mix this with a
> > Scala middle-tier, some groovy glue code and some java
> > highly-performance-tuned areas and you have a nice app, all cohesive
> running
> > on the JVM. This is where I'd liek to see java go, and with the Posse
> > covering topics from alternative languages on the JVM, I see them as
> helping
> > lead the community towards that vision.
> >
> > Please, more interviews on languages like, Fan, Clojure, Scala, Groovy,
> > JRuby, Ioke (preferably from people using them in production
> applications).
> > I'd really like to hear thoughts on Fan's "baked-in" module system vs.
> OSGi
> > vs. Jigsaw, etc.
> >
> > -Josh
> >
> > On Thu, May 7, 2009 at 7:41 AM, Reinier Zwitserloot <reini...@gmail.com
> >wrote:
> >
> >
> >
> > > Trying to prove java sucks by showing code that uses the DOM library
> > > is stupid.
> >
> > > The DOM library sucks. That's what its designed to do; utter bilge for
> > > manifestly typed languages. Fortunately, there's XOM, JAXB, XPath, and
> > > many other alternatives. Not a valid example, unless you want to
> > > highlight that java tends to suck when attempting to use it as some
> > > sort of DSL, in which case: Absolutely right, but coin isn't going to
> > > change this, and there's plenty of resistance to expanding language
> > > flexibility to address such an issue, because it also has many
> > > disadvantages. So, that's a completely different argument.
> >
> > > On May 7, 4:48 am, Josh Suereth <joshua.suer...@gmail.com> wrote:
> > > > Perhaps a better example of scala making life easier. Here I'm use
> "for
> > > > expressions" along with "operator syntax" and "lambda expresisons" on
> the
> > > > Scala XML dom to parse out all link URLs from a web document that end
> > > with
> > > > rpm
> >
> > > > val urls = for { link <- webpageDom \\ "a"
> > > > location <- link.attribute("href").map(_.text)
> > > > if location.text.endsWith("rpm")
> > > > } yield location.text
> >
> > > > Here's similar java (but using a different path)...
> >
> > > > List<String> urls = new ArrayList<String>();
> > > > NodeList links = webpageDom.getElementsByTagName("a");
> > > > for(int i =0; i < links.getLength(); i++) {
> > > > Node link = links.item(i);
> > > > if(link instanceof Element) {
> > > > Element linkAsElement = (Element)link;
> > > > if(linkAsElement.hasAttribute("href") &&
> > > > linkAsElement.getAttribute("href").endsWith("rpm")) {
> > > > urls.add(linkAsElement.getAttribute("href");
> > > > }
> > > > }
> >
> > > > }
> >
> > > > Groovy provides an "XmlParser" for nicer syntax as well.... However,
> > > I'll
> > > > let a Groovy expert show the simplified code for this (I'm pretty
> sure
> > > it's
> > > > close to a one liner using a depthFirst call with a closure filter.
> >
> > > > Lastly, here's a JavaScript example (using jQuery):
> >
> > > > var links = [];
> > > > $('a').each( function(idx, link) {
> > > > if(link.href && link.href.match(/.*rpm/)) {
> > > > links.push(link.href);
> > > > }});
> >
> > > > //Note we are not using map because we want to filter based on link
> > > ending!
> >
> > > > Anyway, on to the point: Which of these has the least signal to
> noise
> > > > ratio? Which one is the clearest? I leave that for you to decide.
> >
> > > > I also want to point out that this expressiveness (of other languages
> vs.
> > > > java langauges) is not limited to XML parsing. I would also be
> remiss if
> > > > not mentioning that I neglect to include a C version of the XML code
> > > because
> > > > I just didn't feel like taking the time to write one, and then make
> sure
> > > it
> > > > compiled/ran. I'd love to see a JavaFX script version of this code,
> as I
> > > > have a sinking suspicision it will still have higher SNR than Java.
> >
> > > > -Josh
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
