Found 3 comments on HN
e12e · 2016-02-24 · Original thread
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: ). 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.


e12e · 2014-07-26 · Original thread
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).



e12e · 2013-10-28 · Original thread
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:

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

Get dozens of book recommendations delivered straight to your inbox every Thursday.