Readability
Reinier Zwitserloot
reinier at zwitserloot.com
Thu Dec 23 15:00:34 PST 2010
You're making three mistakes here:
1) In regards to cucumber, well, uh, "Applescript". That answers that.
Readability is great. Readability does not, however, mean: "It looks just
like an english sentence". Also known as the: "To a programmer, minutes(5)
is likely to look more natural than 5.minutes, rails notwithstanding"
principle.
2) about readability: You make a claim that one example is much easier to
understand than the other, and you leave it there. As if its self-evident.
It isn't. I found the current proposal more readable, personally. As has
been mentioned, your obfuscated styling didn't help.
The lesson here is: Don't mistake your personal tastes for some universally
accepted readability standard.
3) Your example of the current proposal uses a crappy API syntax. Mark
Thornton has done a good job of showing a better design. Because language
features take so much time and care, its generally a better idea to attempt
to design your API around the language, compared to designing the language
to fit the API flavour of the day thats popular. (Also known as the: 'Don't
add XML literals just because they happen to be in fashion this year'
principle).
Also, java8 will have extension methods. I'm guessing your point is: You're
worried that the current lambda proposal is not particularly robust in the
face of crappy API designers. This could be a valid concern (In retrospect,
checked exceptions shouldn't have been tried because at least for the first
10 years of java, not one API designer grokked them, and now we're stuck
with boatloads of inconsistent application of the checked / unchecked
distinction), though as Brian has said, use-site extension methods (which
admittedly is a decent way to patch up crappy APIs), are out. No sense
opening up that can of worms again. I suggest we don't start hacking away at
the lambda syntax based only on a _fear_ of widespread abuse. If it comes to
that, some features to help deal with bad APIs can be added later (such as,
for example, use-site extension methods!)
NB: I believe the time to chat about the syntax specifics isn't here yet. I
presume Brian or Maurizio will let us know when the time has come to grab
our paintbrushes.
--Reinier Zwitserloot
On Wed, Dec 22, 2010 at 6:59 PM, Llewellyn Falco <isidore at setgame.com>wrote:
> Yesterday I gave a talk entitled "why I love java" at a local user group (
> www.sdjug.com )
>
> At the end of the talk lambdas came up. It reminded me of just how
> confusing
> lambdas are for many people out there.
>
> Now, keep in mind that I am an Instructor for Developmentor (
> www.develop.com ). I am constantly introducing people to lambdas. So I
> have
> a pretty good idea of how people "can" react to lambdas.
>
> Still, this caught me off guard, and I realized that the big difference was
> we had to talk about the "mechanics" of lambdas. Which is very confusing to
> people. Instead of showing lambdas and let people understand *what *they do
> 1st. They can learn the *how *latter.
>
> I'm going to give you guys an example from ruby 1st, because I'm hoping you
> haven't seen it yet.
>
> Feature: Division
> In order to avoid silly mistakes
> Cashiers must be able to calculate a fraction
>
> Scenario: Regular numbers
> * I have entered 3 into the calculator
> * I have entered 2 into the calculator
> * I press divide
> * the result should be 1.5 on the screen
>
> This is a cucumber test from ruby. Do you understand *what* it does?
> Could you change it to do other things? I'm guessing you could.
>
> Now, can you tell me *how* it works? The above code is creating
> object, and calling methods with parameters. Which methods? Which
> parameters? Which Objects?
>
>
> The thing is, after using cucumber for a while, you can start to tease
> out the *mechanics* of it. But because it is so very readable, you
> don't need that to use it.
>
>
>
> Now, lets jump back to lambdas. What I want to plead for is *extreme *
> readability. I believe this comes form 2 things
>
> 1) the lambda itself
>
> 2) extension methods (no reverse polish notation)
>
>
> let's say I have a list of people, and I want to get a all of there
> 1st names, that are less than 10 letters long, ordered from short to
> long (this is a slightly more complicated version of something that
> came up last night)
>
> Here that is using the current proposed 1.8
>
>
> List<String> sorted = Query.orderBy(Query.where(Query.select(people,
> #{p->p.getFirstName()}), #{p-> p.length() < 10)), #{p->p.length});
>
>
> this confused people. a lot!
>
>
> So we went to C# and worked backwards. Here it is in C#
>
> var sorted = people.select(p=>p.getFirstName()).where(p=>p.length <
> 10).orderBy(p=>p.length);
>
>
> (Notice how much easier this is to understand!)
>
> Then we converted it to java as if we had extension methods.
>
>
> List<String> sorted =
> people.select(#{p->p.getFirstName()}).where(#{p->p.length <
> 10}).orderBy(#{p->p.length});
>
>
> good. It's easier to follow the additional clutter of the lambda syntax
> now.
>
> Then we put it in the needed order.
>
>
> List<String> sorted = Query.orderBy(Query.where(Query.select(people,
> #{p->p.getFirstName()}), #{p-> p.length() < 10)), #{p->p.length});
>
>
> This helped a lot of people to sorta figure out *why they might want
> lambdas*. But it took a lot away for my talks point "why I love java"
> and left people wondering about c#....
>
>
> Llewellyn
>
>
More information about the lambda-dev
mailing list