Sean Landis
Posts: 129
Nickname: seanl
Registered: Mar, 2002
|
|
Re: invokedynamic on OpenJDK
|
Posted: Sep 3, 2008 8:59 AM
|
|
> > Hiding language complexity from our staff via a
> framework
> > that simplifies/limits options, and enforces practice.
>
> Maybe you mean something different than what I read from
> this but 'hiding complexity', to me, is demeaning to your
> developers. Abstraction to me is about dividing up a
> problem into manageable bits. 'Hiding' reminds me of my
> PowerBuilder maintenance nightmares from long ago. I
> think the developers must be able to move up and down the
> abstractions freely. Nothing should be hidden.
We get many benefits from our frameworks. Abstraction which helps hide complexity, reuse of common code, enforcement (or maybe encouragement is better) of practice, and quality in the sense that much of the very tricky code is abstracted within the framework.
AFAIK, there's no way to prevent people from not using a language feature, and we don't prevent anyone from doing so. Therefore, I see nothing demeaning about it. In fact, our staff is entirely mid- and senior level developers. We expect them to be able to use generic classes (although not necessarily write them), we expect them to be clients of most all Java features.
Using features like generics is a much lower bar than creating generic classes. We find it is a good balance and since JEE-style environments have the same expectations, I don't see this expectation as a stretch.
To help keep people on track, we provide quality JavaDoc, Wikis, mentoring, etc. Our staff is about 60 developers.
> I'd be interested in your approach to addressing the
> complexity of Scala. I thought your talk at Java One was
> one of the best I attended (I attended too many) so I mean
> this sincerely.
Like with Java, an organization can choose to proliferate or limit the use of language features. We don't discourage people using difficult features but we provide easier alternatives. In Java, most organizations can easily avoid the difficult parts if they choose.
Our model, which is not revolutionary by any means, is to have a small team (we call it Architecture) that tackles the tricky stuff and provides it for the staff. They also provide consulting when the teams need to do something tricky themselves. Provides a great learning opp.
The first thing about Scala is you have all the benefit of Java in the sense that you get to use all the libraries and you can create your own.
Additionally, you have ways to extend to language easily to create internal DSLs that seem as though they are part of the language. This, in our organization, would be build primarily by the Architecture team.
As before, being a client of code that was built using "complex" features is much more approachable than writing the code that uses those features. There's nothing in Scala that would prevent us from utilizing this approach that has been successful with Java.
In a different direction, I think that many who declare Scala complex are really misinterpreting "different" as "complex." Most mainstream programmers haven't been exposed to functional programming. The same was true when C++ was introduced; few people had been exposed to OO and it was considered complex but was actually simpler but different. Hell, C++ IS complex but not because of OO.
Some think that the inclusion of operator overloading and multiple inheritance Scala is a bad idea and point to experience with C++. Those features were problematic in the C++ implementation but not nearly as much in Scala.
So I think 1) our team already has the tools to deal with complexity, 2) Scala actually will help us more than Java has, and 3) I think the complexity issue isn't as big as people fear. People just are fearful of change.
> I have doubts about this. I was really excited about
> Scala for a while but after being on the mailing list for
> years while, I feel that it's lost direction. It's being
> steered by the interests of people with too much brains
> but not enough sense.
I think people forget how long C++ and Java took to mature. The champions were perceived as brainiacs but the languages became mainstream quite quickly.
At JavaOne there was quite a bit of uptake on Scala. I think it is far from stagnant. I think developers have gotten hooked on measuring viability according to hype. Scala hasn't been hyped. My initial reaction to hype is usually an allergic response.
> > After interviewing 100s of developers, I can say with
> > certainty many so-called senior developers do not
> > understand 1.4.
>
> No question. But I think that 'real' developers will have
> little trouble with it. My personal experience with
> developers that don't really understand they tools they
> are using comes from my work with COBOL developers. Most
> COBOL developers will tell you that COBOL is simple but
> can't explain how it works. That makes me uncomfortable
> to the extreme.
"Real Developers" have no trouble with 1.5 either. I don't think there is anything simple about COBOL ;-)
> > So hire dumb developers so they don't use smart
> features
> > to solve problems. Makes perfect sense. And make sure
> the
> > languages stay dumbed down so the dumbed down
> development
> > staffs don't get themselves in trouble. Got it.
>
> This is what I figured you think I am arguing but it
> isn't. Java isn't the most complicated language. It's
> not the simplest language either. I think it's about the
> level that anyone with a little motivation and skills in
> logic can get within a few years. My personal opinion for
> why most 'senior' developers don't understand Java is too
> much reliance on frameworks. They are a crutch. Every
> developer I've mentored with a framework background has
> figured out Java in no time once they were asked to
> actually do real Java programming.
I agree that certain frameworks have led to the dumbing down of the development community. They don't need to understand the language, just a few constructs and annotations. I refer to them as "Bean Programmers." Very dangerous folk if you have hard problems to solve. We hire people that have a good understanding of the language first.
Here's my view: Frameworks (IDEs, etc) are power tools. In the hands of a craftsman, great things can be built. In the hands of a neophyte, someone is going to get hurt.
> To me your argument sounds like it is for classes (or
> castes) of developers. I think that's bad policy.
Not in our environment. Hopefully I've made that clear. But, I do believe the marketplace HAS created classes of programmers.
> > Can you give an example?
> Implicit conversions, especially global implicit
> conversions.
Take them or leave them. You can be explicit in Scala. Fortunately, unlike other languages, the IDE can help here. IDE support is very important.
> No, I think 1.5 takes too much focus off of what I like to
> call "getting shit done" and puts it what I call "circle
> jerks". The features are not efficient for a large team.
> There's too much friction. When there's only one way to
> o do things, there's no arguments about whether you are
> doing it the right way. Of course there's always more
> than one way, but limiting the possibilities creates less
> of a drag on the team.
We gain great productivity (and maintainability) thanks to features like generics. It's an organizational issue, not a language issue. Understand what the team can tolerate and arrange to avoid anything beyond that. I've described what we do in that regard.
> I think it's possible to create a new language that's more
> powerful than Java and less complex. That's what I'd like
> to see and Scala ain't it.
I'm waiting for that language too! In the meantime, our company needs something more powerful than Java 1.6. The blowing wind seems to indicate generics might not get fixed (erasing erasure), BGGA won't be included, and instead more crap will be stuffed in. I harken to the inclusion of XML, CORBA, JAXB, etc, into the JVM rather than leaving them as extensions. These sorts of 'enhancements' have truly undermined productivity for us as we try to work around them.
|
|
Previous Topic
