dynamic classes and duck typing

[dsimcha]

== Quote from Roman Ivanov (x at y.z)'s article
> Walter Bright Wrote:
> > dsimcha wrote:
> > > Right, but sometimes (though certainly not always) it's better to provide a
> > > meta-feature that solves a whole bunch of problems (like better templates) and
> > > then solve the individual problems at the library level, rather than add a
> > > language feature specifically to address each need.
> >
> > Yup. The hard part, though, is figuring out what the magic set of
> > seminal features should be.
> >
> >
> > > One thing D does very well is
> > > allow you to do the same kind of metaprogramming solutions you would do in C++,
> > > except that the result doesn't suck.  For example, std.range implements
> > > functional-style lazy evaluation as a library, and does it well.  The point is
> > > that, if you can't deal with the complexity of having real templates, you better
> > > be prepared for the complexity created by not having them.
> >
> > Right. A "simple" language pushes the complexity onto the programmer, so
> > he has to write complicated code instead. D programs tend to be
> > dramatically shorter than the equivalent C++ one.
> >
> >
> > > Having never done it before, I really cannot imagine how people get any work
done
> > > in a language that doesn't have either duck typing or good templates.  It's just
> > > too rigid.  It seems like modern statically typed languages like Java and C# end
> > > up adding tons of ad-hoc workarounds for lacking either of these as
> > > well-integrated language features.  The best/worst example is auto-boxing.
> >
> > I tried programming in Java.
> >
> > A friend of mine had an unexpected insight. He used Java a lot at a
> > major corporation. He said an IDE was indispensable because with "one
> > click" you could generate a "hundred lines of code". The light bulb came
> > on. Java makes up for its lack of expressiveness by putting that
> > expressiveness into the IDE!
> >
> > In D, you generate that hundred lines of code with templates and mixins.
> I'm a Java programmer. IMO, the biggest problem with Java is not the language
expressiveness, but poorly written APIs and badly selected abstractions. The
reason I can't program in Java without an IDE is (usually) not because I need to
generate tons of code, but because I'm constantly looking up new method/class
names, looking up packages to export and refactoring.
> A lot of things that require extensive code generation do so simply because they
are badly designed. Web services (SOAP based) are a good example of that. In the
end, it's just reading and writing text to a socket. It could be very simple, but
it isn't.
> An area when I find myself using code generation a lot is exception handling. I
prefer to write my code without handling exceptions at all, and then let API to
generate try/catch blocks. I tweak then afterward. Thing is, Java supports runtime
exceptions that don't cascade in kilobytes of mostly useless code. People just
don't use them that often.
> My point is, language is one thing, but "language culture" is another. For some
reason Java bred a culture that encourages bloated, counter-intuitive,
"enterprise" solutions. It's not inherent in the language. It has more to do with
the companies that use it, core API design and design of popular libraries. At
least that's the way I see it.

Yes, but in my (possibly somewhat uninformed) opinion, the root cause of this is
that Java just doesn't provide many tools for managing complexity.  Complexity has
to go somewhere, and about the only tool Java provides for managing it is OO-style
class hierarchies.  I have nothing against OO, classes, interfaces, inheritance,
etc.  It's just that it's not the right tool for every job.  If your problem
doesn't fit neatly into an OO-style class hierarchy, it will be made to fit
sloppily.  In a more multi-paradigm language, you might use templates, or duck
typing, or higher-order functions, or closures, or eval statements, or mixins, or
macros, or whatever complexity management system maps best to the problem you're
trying to solve.  In Java, by going overboard on making the core language simple,
you end up pushing all the complexity into the APIs.