HN Books @HNBooksMonth

> was not sure if the choice of language (Java)

Two books I enjoyed despite, rather than because of the language:

"Program Generators with XML and Java" (aka "program generators for fun and profit") https://www.amazon.com/Program-Generators-Java-Craig-Cleavel...

And:

"Designing Active Server Pages" https://www.amazon.com/Designing-Active-Server-Pages-Mitchel...

The latter mostly for techniques to keep programs structured even when writing mostly in template soup (like php, asp, coldfusion etc).

The sibling comment alludes to parsing calendar events (possibly .ical files). In general you need it for any kind of (de)serialization -- and as the recent java deserialization bug[1] (along with similar bugs in python, ruby) illustrates -- even in a mature language, "common practice" might not be "best practice" (everyone should've known that the various uses of blind deserialization was a bad idea -- but that doesn't really matter after the fact -- lots of high-profile libraries were completely broken). So "just use a library" might not be possible.

Any time you take native objects/data and persist them, or marshal them, you need a parser -- or a parser library. That might mean reading some CSV, parsing some XML, reading some YAML, JSON or what-not.

Then there's configuration that does more than set some variables, like for Nginx, Apache (web server), etc.

One might want to have a short-hand for defining templates -- either for general meta-programming, or just to generate a layout-language (eg: html, css). If you're doing markdown (or markdown-like) processing, you might want to have some assurances that that's all that code can do -- generate html. Or you might want do meta-programming on some higher level, like generating interfaces for some java-beans based on a CSV structure. For more on meta-programming in Java, I recommend (the now slightly dated: http://www.amazon.com/Program-Generators-Java-Craig-Cleavela... ). It's a shame he didn't name it as he claims he considered in the foreword: "Program Generators for Fun and Profit!".

And finally there's "real" programming languages - full blown DSLs of some kind. Perhaps in an effort to represent some kind of business logic (eg: authorization based on group membership, roles and time of day) in a language that is "safe" -- has no side-effects.

[1] http://fishbowl.pastiche.org/2015/11/09/java_serialization_b...

http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod...

I think the FactoryFactoryFactory-(anti)-pattern and bloated xml-configs are an enterprise thing, that by accident became a java thing (as java was adopted by people that were used to fighting with multi-kloc-c++ code-bases).

Another (related) java culture mis-feature is the tendency of "horizontal abstraction". Rather than building useful abstractions, there seems to be a tendency to move parameters from (initialization) code to xml to ini-files that generate xml to... All the while not really building up vertical abstractions where there sits something simple on top -- but rather just shifting the complexity "sideways" -- moving it around rather than collecting and simplifying.

I think part of this started before generics were introduced, as an artefact of java being a "compiled" language without any dynamic code-generation. So everyone ended up writing their own, strange, meta-programming language based on XML. Which can be fun as an exercise[1], but pretty poor in terms of tooling/ecosystem.

What java probably needed from the start was something like groovy -- and yes, my impression is that the ecosystem is becoming more sane.

BTW, java doesn't have multiple inheritance (well, it might have now that you can add some (static)code to interfaces[2]) -- it has (weak) contract based programming (via interfaces).

[1] http://www.amazon.com/Program-Generators-Java-Craig-Cleavela...

[2] http://docs.oracle.com/javase/tutorial/java/IandI/defaultmet...

⬐ vorg

> What java probably needed from the start was something like groovy

Jython (then called JPython) came along fairly early, in 1997 and feature complete but never took off for testing or gluing Java code. Jacl, a Java version of Tcl, also came around 1997 but virtually no one used it. Beanshell was built before Groovy, removing static typing but keeping the rest of Java's syntax. Groovy duplicated Beanshell's use case but brought closures and terse collections syntax, but didn't get any significant users until the Grails project spent a year (2006) retrofitting it with a meta-object protocol so it could be used with Grails. A second growth spurt happened in 2009 when Groovy added a DSL syntax to its already klunky grammar so Gradle could use it. Though you could argue Groovy's use in Gradle builds isn't very significant because the build files are typically 20 to 50 lines long, using the DSL syntax only and not making any use of the actual Groovy language features. And Gradle may not use Groovy as a build language for much longer. Calling Groovy an "overhead in the IDE-to-Gradle communication", the recent Gradle 2.0 roadmap [1] says:

"Android Studio demonstrates the enormous potential of a deep integration between the IDE and Gradle. At the moment, the price we pay for this is often mediocre responsiveness: every time the IDE makes a query of Gradle, the configuration phase is run before an answer can be given. The folks at Google are implementing some smart workarounds for this. But what is ultimately needed is a fundamental solution within Gradle that eliminates the overhead in the IDE-to-Gradle communication."

[1] http://forums.gradle.org/gradle/topics/revolutionary_new_gra...

⬐ e12e

I should perhaps have been a little more clear: I didn't mean to imply there were no scripting languages for java, just that they weren't first-class citizens of the platform (Beanshell being an exception -- but perhaps it too suffered from being a bit heavy?).

It's interesting that Gradle seem to be moving away from Groovy -- especially considering the section on configuration: It appear they're moving towards a functional-flavoured architecture -- and at the same time further specializing Gradle -- so that it'll (probably) be a better build tool -- but also quite useless for other tasks/customization. Or rather; it would appear the project will not be much of a driver in improving Groovy for projects that need some form of dynamic configuration etc.

On the other hand Gradle will (presumably) serve as nice architectural model to follow for other projects (move towards a functional style, rather than programming dependencies in a procedural manner with a hacked up xml dialect).

Perhaps one of the core issues have been projects mixing complex configuration requirements (eg: routing for tomcat) with simple requirements (eg: username/password etc -- stuff that works well in a ini-like format). I suppose that if you've determined you need complex/powerful configuration, you'd be hard-pressed to include a second form of configuration in your project. After all simple xml files are almost as readable and easy to work with as ini-files... And yet, for a lot of projects, it's ended up being a bit of a mess.

I'm not entirely certain that is a plus... Is writing a compiler/translator in xsl really more pleasant/easier to maintain than writing it in a "proper" language?

That said, I really enjoyed: http://www.amazon.com/Program-Generators-Java-Craig-Cleavela...

edit: for example: you could transform an ant build.xml file -- but should you?