context and background:

I prefer OOP for the most part and find it, largely, more intuitive -- this is my bias.

When I read that functional language x is better than OOP language y I think to myself: sure, sounds great, if you're computing integrals or performing other mathematical operations. Outside of that domain, I don't appreciate the appeal.

That being said, I do note that http is stateless and so, as with OOP and RDBMS, or SQL, there's a mismatch. Why? Because objects have state, that's the intention of the paradigm. At least, this is my perspective.

I find myself dipping my toes in XML processing, which can use such oddities as "out parameters" for performance. It just seems a mismatch, not just for that reason. Alternately, potentially huge classes can be autogenerated for jaxb, and there some, perhaps, better approaches as well -- but none of them "feel like" a good fit for xslt.

Here's the question in two parts:

  • Are OOP languages, such as Java, inherently at odds with XSL?
  • If so, would a functional language better fit XSL transforms?

Yes, I'm aware that xslt is a functional language itself, or at least influenced by them. As a practical matter, the xslt processor is used by a more general purpose language.


Perhaps I'm misunderstanding or not appreciating the xslt expressions and how they relate to objects. I say that because the above graphic looks very, well, object oriented, for lack of a better term...

  • 1
    What do you mean by mismatch? There are xslt processors written in Java... XSL and OOP are different tools for different problems. Jan 12, 2019 at 23:19
  • Perhaps out of bounds, but the subtext is meant to be: what's the ultimate tool for using XSL?
    – Thufir
    Jan 12, 2019 at 23:39
  • Your question is extremly vague. Without a more practical example showing the issues you have in mind, don't expect it to survive on this site. It will probably closed as "unclear".
    – Doc Brown
    Jan 13, 2019 at 8:25

4 Answers 4


There is no mismatch between stateless systems and OOP, any way of writing software is independent from a system trait. You can make a stateless service using an OO language just fine and you will likely use some stateful objects in the process. The resulting system will only be stateless from the user's point of view.

XSL is not an object oriented language but that does not mean there is some sort of beef between XSL and other programming languages that have different purposes. XSL is a dedicated language with one purpose: transform XML documents into something else. It is pointless to compare that to general purpose OO languages.

The industry has many programming paradigms that peacefully co-exist, each serving a different purpose and catering to a different need.

  • not intending to ask, or imply, a beef between paradigms. But, I'm curious about your remarks over there not being a mismatch between stateless systems and OOP. I always took OOP to inherently involve state? At least, this being the impetus for the creation of OOP?
    – Thufir
    Jan 12, 2019 at 23:44
  • @Thufir OOP is keeping data and logic together. If you have any data that is, you can write classes with just logic. But even if you have data in a class, that data does not necessarily represent state in the overall system. And if it does it may be temporary state in the context of one service call, leaving the service stateless from a client's perspective. So OOP does not make it harder to write stateless systems just because it supports state on the object level. Jan 13, 2019 at 6:59

Interfaces between interpreters of different languages are always a little painful. XSLT is best thought of as a domain-specific programming language (it's Turing-complete, after all) for transforming XML documents. It isn't itself an OOP language, so of course it isn't going to follow OOP design philosophies. You shouldn't try to shoehorn it into that model. Similarly, we don't worry about objects corresponding to matching subcomponents of a regular expression. We're using a specialized language to solve a problem it's designed to solve.

That doesn't mean you shouldn't use DSLs. When XSLT is the best tool for the job, it's better to use it and deal with a little clumsiness in the Java API to the XSLT processor than to try to write the same transformation in "true" OOP form. You'll get shorter, more robust, and more maintainable code for it.

  • 1
    thanks for articulating my difficulties. Leaving open for a bit, but that puts me at ease.
    – Thufir
    Jan 12, 2019 at 23:38

A transformation is a pure function from input to output, and there's no problem invoking pure functions from any kind of language whether it's imperative, declarative, functional, object-oriented, or whatever. So invoking XSLT transformations from other languages is no problem, whatever their paradigm.

On the other hand invoking Java methods from XSLT is fraught with difficulty, because Java methods have side-effects and XSLT is purely functional, so order of execution is not defined. Implementers and users get around that problem pragmatically, but it will never be clean.


First, a bit of clarification: putting aside the "purity" aspect for now, OOP and Functional programming are not inherently different. The defining trait of Functional programming is solely that you can generate callable functions at runtime, usually by "composing" other, already existing functions, sometimes with non-function data in addition. This results in your new function having hidden state, which makes them equivalent to objects (question: how does Lisp implement an object? answer: by encoding the object members inside of a single function which itself acts as a dispatcher for all interactions with the object!).

As far as "purity" goes, pure functions may sometimes be forbidden from modifying their hidden state, but that in itself means nothing. When viewed from the perspective of the produced executable instead of the source code, purity within functions means only that the output depends only on the input. If you take a Java class that implements a single method, which in turn takes two arguments and returns their sum, then that method is functionally pure. From this, the possibility of building pure functions within Java starts to come into view.

The final trait worth particularly drawing out is memory management: due to the need to manage hidden state within functions, functional languages traditionally include a garbage collector to avoid forcing the programmer to manage it manually. Java, as you should know, also has garbage collection.

With that, you have functional programming in Java, and the only thing you might be wanting is a function annotation that tells the compiler to forbid "impure" code to be called by one of the annotated functions.

So, OOP is not inherently at odds functional programming. But what about with XSL? What is the "ultimate tool for using XSL"? Well, the ultimate tool is a parser system, not OOP or Functional Programming. Both of those are completely tangential to the subject.

Here's an excerpt of Wikipedia:

  <person username="JS1">

Gets taken by:

  <xsl:template match="person">
    <name username="{@username}">
      <xsl:value-of select="name" />

And turned into:

<name username="JS1">John</name>

So, the template gets applied within the context of any person tag, is allowed to see the contents of that tag, and everything inside the tag is visible to the template. To deal with this, I would first build a full parse of the XML & XSLT files (I leave the issue of partial parsing to your imagination).

That produces two trees. Each tree is itself composed of nodes which can contain others of their own kind (as opposed to being restricted to some other type). The XSLT tree is itself composed of function objects, that in Java might have an interface like this:

public interface XSLTNode {
    OutputNode execute(XMLNode xml); 

The thing is, each node produces it's output from a combination of only LOOKING at the sub-tree that's handed to it, and the output trees handed to it by the child XSLTNode instances that it calls itself. So, there is state, but that state is unchanging state held within the individual nodes, + a stack trace that keeps track of progress made.

Now, what about {@username}? Well, what about it? "username" gets looked up in the currently active dictionary, and it's value substituted in. The dictionary itself is obtained from the XML node that was handed to the XSLT node, so no particular issue there. The original XML tree doesn't get modified, and the entirety of the output is via the Java function's return.

And John? Same deal, but via a different route: xsl:value-of recieves the child XML node that corresponds to "name", and like {@username} and all other nodes, simply outputs it's contents via the standard Java return route. I'm curious about what would happen if multiple name nodes were present within a single person node (output in whatever sequence they were encountered in, I suppose?), but that's slightly tangential.

Now, from this we get a third tree, which itself is comprised of nodes which all have an interface something like this:

public interface OutputNode {
    void output(DataOutput out); 

Calling output on this results in all of it's child nodes receiving the same "out" handle in whatever sequence that the parent sees fit, as the parent intersperses it's own data. Alternatively, the XMLNode type can itself be the OutputNode type, allowing the option of pipelining XSLT trees before finally settling on a particular tree as being final.

There's just one little thing... moving from the files to the first two trees. How does that work? Well, it depends on the parser. The parser needs to know how to do it's job, but once the parser has done it, all that you have to do is call the XSLT tree with an XML tree as it's argument, and receive the return value as the result. There isn't inherently anything else to it. The parser is, effectively, a black box, and you should never need to know anything about it's internal behavior for any sensible inputs.

Incidentally, HTTP may be stateless, but that only applies between separate sessions (the ability to switch protocols & other things mid-session means that the sessions when taken individually do have state), and doesn't inherently apply to the programs that are being interacted with at all. To use web browsers as an example, the usage of "cookies" commonly results in individual websites gaining the ability to maintain state across HTTP session boundaries.

Not the answer you're looking for? Browse other questions tagged or ask your own question.