Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
(Regarding Closures) Think About Java-Joe!
At 7:06 AM on Aug 23, 2006, Mikael Grev
wrote:
Fresh Jobs for Developers Post a job opportunity
Not only are the guys behind the Closure proposal very smart, they are also experts at what they do. Very probably the best in their field. They are also IMO very intelligent, which means they get the grasp of things very quickly, like most of the people hanging out here at JL I guess. The problem is that no one stands up for the normal, averagely smart "Java-Joe". There is a simple reason for this. He does something else (like having a life,
Closures will make the code harder to read. That's a fact I think no one denies. It sure has its uses and I drool over the clever code I can write and that not many corporate average Joe can decode. Code that I don't understand that they don't understand.
And here in lies the problem. The best of the best, top 0.01% Java developers designs a feature that 99.99% is to use. While Niel Gafter and gang are debating on how to most cleverly implement Closures in Java, I have to wonder whether they actually ask any average developers how they feel about it. Sun have a much much higher standard of their Java developers than the average Java enabled company (for obvious reasons) which makes it hard for Sun to find real users in-house. Heck, even here at JL I would guess most is in the Java coding top 5 percentile. The lion part is out there doing real Java application and they never go online for checking the latest on how Java is evolving.
The proposed specification for closures fail my just now invented quick test. You can try it for yourself. Fire up Niel's blog entry and scroll up and down trying to figure out, at a glance, which code examples uses closures and which don't. I can't do it. They have found a nice expression hole to put closures in, a hole that don't exercise the fingers almost at all. A certain combination of parentheses and curly brackets makes a closure. Neat. This will not, IMO, be easy for average Joe to understand.
I know that it is hard to introduce new keywords and Sun is almost religiously against it, so they will squeeze in closures by filling in an illegal hole in the current combination of statements. I wouldn't mind closures, but they need to be clearer in either syntax or formatting.
If we let experts design features for experts, no matter how clever these features are, we will alienate average Joe, and when he jumps ship, the experts will become average...
I think they should add one more guy, or gal, to the expert group:
For our expert group We are looking for You that have no more than two years of Java practice and are average, or preferably below average, at what you do. You should never have searched for Java related information online other than for solving practical, work related, problems. Your IQ must not be above 110 (we need paper on this). You will be working in a group with very smart people and your primary job function is to say “I don't get it”, when you don't get it. You must have no prior knowledge of closures. In fact you shouldn't even know what a closure is (if such a thing even exist).
Cheers,
Mikael Grev
104 replies so far (
Post your own)
Nobody promised average Joe that he can be a programmer
There are geniuses, there are smart people, average, not-so-bright and the plain stupid. I don't understand why everybody takes it for granted that average or worse people need to be a programmer...If we go further this way, let's simplify grammar and spelling, so not-so-well-versed people can become a professional editors.
Even further - let's look at the medicine and doctors. Why have complicated machines, USG, CT, MRI etc - average Joe probably will not be able to use it to diagnose his neightbour. Not to start with some more invasive tools used for surgeries...
My question is - SHOULD HE be able to?
I still would prefer to think about IT as a kind of elite job. You have doctors, you have lawyers, you have writers, you have programmers. Every of these jobs have certain requirements as far as 'smartness' is concerned. Let's optimize it for genius and smart levels, not for 'average' level.
Re: (Regarding Closures) Think About Average Joe!
That's thread number 4 on this topic.Yeah, they should try to find someone like you described. But hey, wouldn't it be better if they asked for someone "actually really stupid" that "is the biggest possible threat to his co-workers" and "never gets his work done" because he "couldn't get these funny 'if'-things"?
In my opinion you just can't say that so many (95% of all java programmers) are stupid (and that's what you just did).
I won't hire someone who matches the description you gave and you won't do it eigther.
> I can't do it.
I can do it without any problems... though he could've indented the method-declaration of the client-code a little bit more - then it'd have become more obvious.
> Closures will make the code harder to read. That's a fact I think no one denies.
You probably read most of the other threads and their replies and thus you should now as well as anyone else that there are people who argue against this. Actually better readability is one of my favorite arguments.
Re: (Regarding Closures) Think About Average Joe!
> In my opinion you just can't say that so many (95% of all java programmers) are stupid (and that's what you just did).Now where did I do that?
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: (Regarding Closures) Think About Average Joe!
Ok ok. You haven't said that.I overinterpreted that:
> Heck, even here at JL I would guess most is in the Java coding top 5 percentile.
Combined with your proposed candidate for the expert-group and some of the past arguments about closures, somehow drove my imagination to conclude that.
Sorry.
Re: Nobody promised average Joe that he can be a programmer
> I don't understand why everybody takes it for granted that average or worse people need to be a programmer...I'm pretty certain that about 50% of all Java programmers are below average regarding Java programming. Wouldn't you agree?
Regarding the rest of your reply I guess you are either joking or want to have some kind of elite society?
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: (Regarding Closures) Think About Average Joe!
NP Patrick. I just would have been ashamed of myself if I did actually say it..MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: (Regarding Closures) Think About Average Joe!
Ehh, everybody thinks that they are amongst the most intelligent 5%. Everybody thinks that their company/department employs people from the most intelligent/best 2-5% percent. But that's bullshit. (I've read an article how a particular company hired the best 2% by only accepting 2 from a 100. I think it was thoughtworks. This is stupid of course.)Re: (Regarding Closures) Think About Average Joe!
I think one of the main problems is going to be how to explain when to use interfaces and classes (anonymous or not implementing those interfaces) and closures.Where alternatives exist (e.g. in the different loop constructs) in Java it is generally easy to explain which are best to use in what circumstances.
With function types and closures I think it will be much harder to write a short, simple to understand, explanation of when they should be used as opposed to when interfaces and anonymous classes should be used. This is made harder by the standard Library being full of uses of interfaces where closures might be more natural.
Re: Nobody promised average Joe that he can be a programmer
> There are geniuses, there are smart people, average,> not-so-bright and the plain stupid. I don't
> understand why everybody takes it for granted that
> average or worse people need to be a programmer...
You are my hero! lol
I agree with Artur Biesiadowski for the most part. No matter how "simple" you try to make it, building applications and reporting data is inherently complicated.
Even if you could build technology where anyone can do anything they wanted, you'll still get screens with neon orange text on a neon yellow background, no error checking, and reports full of data that people can't use.
Software development is a science, a discipline, and is as intensive as any other profession to do it correctly. I can certainly put a Band-Aid on an ouchie, but you probably don't want me to prescribe you medication for high blood pressure or perform open heart surgery.
I have my own issue with closures, and I do agree that advancements in software development should allow me to do my job better, faster, or more reliably.
To exclude features because the average joe can't figure it out is bad mojo. How does joe progress from average if he never learns anything new? Think about it.
Re: Nobody promised average Joe that he can be a programmer
> To exclude features because the average joe can't figure it out is bad mojo.True. But I meant that the feature should be crafted to take his needs and abilities into account.
Cheers,
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: (Regarding Closures) Think About Average Joe!
Closures aren't that difficult to understand. I think the problem is that the concept is foriegn to most programmers - it just takes a little getting used to. I heard the same arguments against OO awhile back... "too complex, most people won't understand, will get abused, etc"I'm in the camp that most programmers are well above average compared to the general population. Any decent programmer should be able to get the concept. If not, they probably shouldn't be a programmer and I wouldn't hire them
Re: (Regarding Closures) Think About Average Joe!
> I'm in the camp that most programmers are well above average compared to the general population.I agree. Note that I just meant that the spec should be crafted to also fit the average developer .
For the record, I understand closures. But I also understand that syntaxes need to be clear and technically elegant is not always the smartest route to take if something is to be used and liked by the average developer .
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: (Regarding Closures) Think About Average Joe!
I also worried when I read Neal's paper that he didn't have a simple, compelling example. Compare that to the explanations of the new JDK5 features: http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#langQuite a difference!
> Closures will make the code harder to read. That's a fact I think no one denies.
No, they are saying it makes the code easier to read, not harder. I'm not sure I agree just yet, but it's certainly less "syntactic junk", but a little more confusing if you're not used to it.
Re: (Regarding Closures) Think About Average Joe!
> Closures will make the code harder to read. That's a> fact I think no one denies.
I deny it. In fact I consider this claim absurd and I think the onus is on you to demonstrate objectively that closures will make code harder to read. For example, you could do a review of languages that have closures -- like Smalltalk, Ruby, Groovy and many others -- and see how they are "hard to read". If this is a joke... it's a bad one.
Notice btw that the syntax of inner classes is worse than closures, you gotta write much more code for the same task, it's more complex semantically (e.g., people must learn that they can use local variables/params from the enclosing scope but only if they are final, for which there's no decent reason), it was NOT a familiar construct for "average Joes" back in JDK1.1 time when they were introduced; still, it's closures that you deem "hard"?
And whet do you say of the increasing popularity of dynamic languages, perhaps their users all all top-5% hackers? And what about closures in C# 2.0, you say that all people bolted onto the Microsoft platform are top-5% developers?
The reality is that closures are just a matter of culture... first you ignore them, then you think they're hard, and finally, you can't live without'em.
Of course not all programmers will use closures to write sophisticated tricks like rolling their own control structures. I expect the "average Joe" to use closures for little more than writing Swing listeners, Runnables, Comparators and other simple things that use inner classes today. And yes, God Hackers can use closures to write code so sky-high that average programmers will have problems to understand it at first sight; but then, this is true also without closures, and in my experience this "skills gap" is more frequently related to other factors than language syntax. For example, try showing a complex concurrent algorithm to a mediocre programmer and see how he chokes on that, no need of fancy syntax.
> I know that it is hard to introduce new keywords and
> Sun is almost religiously against it, so they will
> squeeze in closures by filling in an illegal hole in
> the current combination of statements. I wouldn't
> mind closures, but they need to be clearer in either
> syntax or formatting.
So far I don't see how new keywords or lexical elements would enhance the syntax. Of course this initial proposal is a very bare draft, I guess the syntax may still evolve.
Burt remember that Java, for good or bad, is a static-typed language, so it's not feasible to achieve a trivial closure syntax like Smalltalk or Groovy, not matter how many tricks you use. It's not a matter of introducing keywords. Perhaps we can have more type inference.