[JanezStupar]

Python itself has DI built in throughout the stack.

Building Java like DI mechanisms is cargo cultism. The whole point of DI in Java is to work around its static typedness, so one can perform runtime binding of components in a dynamic manner.

Three quarters of cool Java and .NET "design patterns" are just band aids around semantic limitations of these languages.

[altcognito]

> The whole point of DI in Java is to work around its static typedness.

So, coding the configuration of your application is an ideal way to work. Interesting.

[JanezStupar]

Yes!

http://thedailywtf.com/Articles/Soft_Coding.aspx

If Java guys wouldn't have stuck their heads up their asses so hard, they could use something like scripting language, with the whole debugging and library stack to configure their applications instead of building byzantine XML based DSL's.

Frankly my python (code!) based config files work a lot better than similar XML based config files in Android. Except mine are debuggable and readable.

The whole point of software is that it gets changed on demand. That's why it is called SOFTware.

Edit: Or perhaps you are going to enlighten me why XML config files are not code? Then you might be able to explain where configurations cross the border of "code". Is configuring Sharepoint coding or configuring?

[altcognito]

Readable to who? Machine readable? Which is easier to change or debug: dependencies which are in predictable locations OR buried within your source code? Could you say the same thing about arbitrary python code? Now I have to learn the way you decided to implement what's already been done dozens of times before I even get to reading the actual logic of the application.

Also, for the record, if you're debugging the infrastructure of how objects are created, you're doing it wrong. You probably don't understand the framework you're working in.

[JanezStupar]

You are missing the point. I am not saying that one should make mess of his code.

I am merely saying that configuration files are code too. They need to be tested, debugged and refactored. Writing code in XML seems a retarded way to go about it. If my language would prevent me from writing configurations in itself in a sane manner, I would rather use another language with a solid toolchain for this part of the job. Than go and build my own DSL in XML of all things.

If you are of an open mind, go check how Django is configured and extended and compare it to your run of the mill enterprise framework.

And let me tell you that I did my fair share of enterprisey "configurable and extendable" framework shit. And its all a lie. You cannot make "simplified" languages that will enable you to be more "flexible" or to let amateurs to program system behavior. Always these kinds of interfaces gobble up way more developer hours than they save in the long run. Often programmers resort to writing programs that offer a sane API for writing these kinds of configs.

One should simply build a quality API and document it well.

[dragonwriter]

> So, coding the configuration of your application is an ideal way to work. Interesting.

You're coding it one way or another; whether you do the whole thing in Python, or most of it in Java and some of it in XML (or YAML, JSON, etc.) because Java is inconvenient.

The main motivation for using XML (YAML, JSON, etc. are equivalent for this purpose) "configuration" over Java "coding" for certain pieces is that: 1. XML, unlike Java, doesn't need to be AOT compiled 2. XML is more naturally suited than Java to a succinct declarative style 3. Its easier for external tools to work with and modify XML than Java, which may be useful for configuration tools.

In many other languages, one or more of these advantages of XML over the main coding languages is less significant or entirely absent (interpreted/JIT-compiled languages avoid #1; functional and many modern multi-paradigm languages avoid #2; Lisps and other easily-parseable homoiconic languages avoid #3.) Depending on the language you are using and which of these factors is important to your use case, there may be no significant reason to bear the cost of a second language for configuration.

[altcognito]

> You're coding it one way or another;

Yes. I agree, most of these frameworks are in some sense a DSL. I cannot agree that writing in a different language changes the underlying purpose and function of separating configuration from the code.

[dragonwriter]

> I cannot agree that writing in a different language changes the underlying purpose and function of separating configuration from the code.

Language features effect the degree to which the underlying purpose and function of separating service identification from other code requires framework support, and the style of framework which is most sensible to support it to the degree that framework support is necessary.

[altcognito]

I can agree with that. Untyped languages seem to allow for better gradients of separation as well as tend to work with a wider variety of tools. It's not always good, but it usually quicker to start with.

[manojlds]

Thank you for treating .NET as a language and ignoring languages like F#

[JanezStupar]

I was aware of this dichotomy when writing the post. And I find .NET stack much better than JVM stack.

In fact while I couldn't stomach working in Java I would be much more willing working with C#, not to mention other .NET citizens. But in general as a spectrum, the toolkits and libraries of .NET and Java share architectural and design patterns.

However the .NET stack does have built in languages (Javacript and F#) that can be used to glue together the rest of the system in a sane manner. The capability is there, however standard operating procedure is sadly still using shitload of XML's.