On May 7, 10:25 pm, Josh Suereth <[email protected]> wrote:
> What's a good API to choose? What will be sufficient?
the new File API, the old File API, or the google collections API, for
example.
Here's a fun one, a java JSON API written towards being easy to use,
and readable, in java code:
JSON json = JSON.parse("{foo: 25, bar: [1, 2, 3]});
double x = json.get("foo").asDouble(0.0);
for ( JSON element : json.get("foo").get("bar").asList() ) {
int y = element.asInt();
}
It's my own (though its been submitted for inclusion in GWT core,
because its JSON library was a spectacular example of bad API design -
so far its receiving positive responses, and it's more efficient, both
in code size produced and speed, as the original GWT library, which
just goes to show: API design isn't neccessarily a case of balancing
different concerns. It's a hard job but a proper API is easy,
readable, flexible, and fast). Yet, eventhough I doubt you've seen
this before, I'm fairly sure everyone pretty much immediately groks
how this thing works. If you don't, autocomplete will get you there
(no need even to read the javadoc, that 0.0 argument to asDouble is
for a parameter named 'defaultValue', which you should see in a
tooltip if you mouse-over it. Normally when you stare at code snippets
you're working in an editor and not in a news reader).
contrast this to the crazy hoops that DOM forces you to jump through.
Or, contrast it to what it would look like in javascript or scala.
About as brief, about as readable.
> One of the neat things about the Scala code was that *it is using the DOM*
Scala is DSL-friendly. That's part of scala's design. This also has
disadvantages. Nobody is disputing that scala is DSL friendly. That
also wasn't the point.
> 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.
There you go. Well designed java APIs are usually almost as excellent
as well designed APIs in other languages. I'll admit that java has
more than its fair share of crap, but just saying: Screw it, reset,
and we'll roll with another language - that isn't really a solution,
and it would be naive to think that, if scala ever becomes popular (or
groovy, or clojure, or anything else), that it'll somehow avoid the
pitfall of getting a lot of dinky libraries.
>
> 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).
No, but, the point is - Java isn't the 'assembler' of the JVM world.
You can 'assemble' in scala just as well - though you'd have to jump
through a few hoops, which is fine, because you rarely have to operate
on that level. The point is: Unlike actual assembler, java (the
language) can't get a free ride because "It'll always be relevant as
the assembler of the JVM". It won't be. That's an invalid comparison.
Java::JVM has zippety squat to do with Assembler::CPU opcodes. I don't
know why you made that statement; I was remarking that this (often
argued) non sequitur is something I've heard before, and I expressed
concern that java language designers may cling to this notion, which
would be a grave mistake.
> I can speak from experience. Where are your numbers coming
> from?
experience.
> 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.
That may be what Jess Holle was driving at, but it misses a very
important point: Code brevity isn't about character counts. That's a
gross oversimplification. It's about concept brevity. In many
situations (but certainly not all), looping through a list by way of
running a function on each of the elements is just easier to grok, and
fits closer to the mental model that your code is trying to represent.
The fact that doing this in java is awkward, is a problem, and a clear
win for javascript, python, ruby, and scala. The notion that java uses
'extends' and scala uses '+' for generics, that's almost entirely
irrelevant. If someone has to win that battle, I'd argue java did, by
being easier to understand even when your generics fu is rusty.
>
> -Josh
>
> On Thu, May 7, 2009 at 3:47 PM, Reinier Zwitserloot <[email protected]>wrote:
>
>
>
> > On May 7, 2:23 pm, Josh Suereth <[email protected]> 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 <[email protected]> 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
>
> ...
>
> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
