dynamic classes and duck typing

[Roman Ivanov]

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.