Discussions

News: Allen Holub: Just Say No to XML

  1. Allen Holub: Just Say No to XML (110 messages)

    Allen Holub, in "Just Say No to XML," says that XML is the "worst programming language ever conceived," and blames programmers' lack of knowledge of compiler construction for it. He says it's inappropriate to use XML as a scripting language, test-description language, object-relational language, or a control-flow language, among others.
    Basically, you’re selfishly making your life easier at an enormous cost to everyone else. For every hour you save, you’re subjecting every one of your users to many hours of needless grappling with overly complex, hard-to-learn, hard-to-maintain, impossible-to-read, XML-based garbage. This is no way to make friends and influence people.
    However, one has to note that XML has been very successful in these applications, regardless of whether it's appropriate for these uses or not, and there's also a strength in having a self-descriptive mechanism for these "little languages," by way of DTDs or XML Schemas. What do you think? Should programmers focus on writing DSLs for project compilation (make, anyone?), object mappings, control flows, and orchestration, or is XML good enough for the purpose? Message was edited by: joeo@enigmastation.com

    Threaded Messages (110)

  2. Re: Allen Holub: Just Say No to XML[ Go to top ]

    Well, this is what this dude was getting at:
    My book shows you not only how to build a compiler, but also how to build the tools that you need to build compilers
    Nothing more needs to be added, I gues...
  3. programming language?[ Go to top ]

    Obviously this guy is "misinformed". XML is not a programming language. Maybe he got confused and thought that XPATH is programming. If anything, I'd say XML is like a database and XPATH/XQUERY is equivalent to SQL in terms of data access. Oh well. The guys is still learning what XML is for.
  4. Re: programming language?[ Go to top ]

    True XML is not a programming language though there have been some XML standards that are or are very close. XSLT for example, has loops and conditional logic, etc. You can do a lot of programmming with it. In any case, XML is not the problem, it is how its used. It's extremely useful for many things, yet it is also being misused. So what? Personally I am very glad to have XML because its a powerful way of formatting data with lots of support from tools. I used to have to make do with less powerful formats or invent my own and write my own tools. XML may be flawed, but it works well for what I use it for. Maybe this guy's rant is just to draw attention to help him sell his book. Personally I wouldn't buy a book written by someone who'd make such an uninformed statement and who has such a narrow perspective.
  5. Re: programming language?[ Go to top ]

    True XML is not a programming language though there have been some XML standards that are or are very close. XSLT for example, has loops and conditional logic, etc. You can do a lot of programmming with it.

    In any case, XML is not the problem, it is how its used. It's extremely useful for many things, yet it is also being misused. So what? Personally I am very glad to have XML because its a powerful way of formatting data with lots of support from tools. I used to have to make do with less powerful formats or invent my own and write my own tools. XML may be flawed, but it works well for what I use it for.

    Maybe this guy's rant is just to draw attention to help him sell his book. Personally I wouldn't buy a book written by someone who'd make such an uninformed statement and who has such a narrow perspective.
    First of all, Alan is the leading authority on Object Oriented design and programming. I respect him more than pretty much anyone in the industry, or at least as much as I do Fowler on Patterns. You should read Alan's pattern book, which is a classic. Second, to those who still think that computer book authors make money, need to do more digging. There is no money in writing computer books. Definitely you can make much more billing your client hourly, than spending sleepless nights writing a book that would barely provide enough money to buy food, let along pay bills. Stop spreading this FUD if you have no clue. Ilya Sterin
  6. Re: programming language?[ Go to top ]



    First of all, Alan is the leading authority on Object Oriented design and programming. I respect him more than pretty much anyone in the industry, or at least as much as I do Fowler on Patterns. You should read Alan's pattern book, which is a classic.

    Second, to those who still think that computer book authors make money, need to do more digging. There is no money in writing computer books. Definitely you can make much more billing your client hourly, than spending sleepless nights writing a book that would barely provide enough money to buy food, let along pay bills. Stop spreading this FUD if you have no clue.

    Ilya Sterin
    What does an objection to an ill-informed rant on XML have to do with FUD? What does it have to do with how you feel about the guy's knowledge of OO patterns? Do you know or care what this guy makes from selling his books? Has it occurred to you that people in this business often write books in order to promote their consulting business and their career? There is nothing wrong with that of course, but do you think he writes his books for good of mankind? Your post can be summarized as "I'm upset about people reacting badly to what a guy I admire has written so you should all shut up!" Nice rebuttal. Very on point.
  7. Re: programming language?[ Go to top ]

    you said:
    Maybe this guy's rant is just to draw attention to help him sell his book. Personally I wouldn't buy a book written by someone who'd make such an uninformed statement and who has such a narrow perspective.
    My response was basically to the above statement. Yes, people sell technical books to mostly get their name out and promote consulting careers, not for the good of the society. To be honest, I don't think too many people do things that don't provide them some sort of self-fulfillment. How dare someone promote their hard work, which would mean they are trying to financially benefit, right? Oh, and like that’s such a horrible thing. The issue with your statement is your assumption that because someone mentioned their book in the article that they wrote, they are automatically promoting a book. Maybe they are just referencing material so they don't have to rewrite within the article? And, yes, they might actually think that their material is the best on the topic, wow, that's horrible, how dare they. In regards to the uninformed decision, although I did't agree 100% with the article, I agree with the fact that DSLs would be better suited for most tasks, but whether that's a realistic expectation or not is yet another question. I think you might want to reread the article and other works by Holub, as I'm pretty sure he's more informed than you are .
  8. Re: programming language?[ Go to top ]

    First of all, Alan is the leading authority on Object Oriented design and programming.
    Correction: he is *your* authority. He's certainly not mine (and based on the comments so far, he doesn't get much respect from quite a few people either). Alan likes to write sensationalistic articles filled with extreme statements in order to either: - Get readership. - Sell a book. Today, he's doing the latter, and he's as unconvincing as he's ever been (probably only topped by his nonsensical "never use getters nor setters" article linked above). The bottom line is that a declarative language is needed for certain tasks, and while XML might not be the best language for this, it's still way better than his approach, which basically boils down to "Don't use XML, build a compiler instead". Yeah, right. Buy his book and you'll learn how to write a compiler in... C. Now, that's going to help. I also find it comical that he calls the Aho-Sethi-Ullman book -- one of the most influential books ever published in the computer industry -- a "classic example of everything that’s wrong with academic writing". It almost sounds as if he's trying to sell a book himself. Oh, but wait... -- Cedric
  9. Re: programming language?[ Go to top ]



    Alan likes to write sensationalistic articles filled with extreme statements in order to either:
    - Get readership.
    - Sell a book.
    Again with this sell a book crap. Cedric, how many times can authors tell you that they make minimum wages on computer books and most still think that they actually try to sell them. In that case, I'd be filling most of my posts with book rants too. He's make more money charging a decent hourly rate for a day, than waste the time to write an article to sell a small fraction of a book for miserable comission. Actually, maybe you should write a book on TestNG, I've been searching for one, though the docs are pretty good, you can maybe make some $$$ :-)


    Today, he's doing the latter, and he's as unconvincing as he's ever been (probably only topped by his nonsensical "never use getters nor setters" article linked above).
    Actually, he never says "never use them". If you actually reread the article, you'd notice that it's "most cases" that he's talking about. From an OO perspective, it's unnatural to access object state for processing, rather than asking an object to perform the task. I won't get into it here, but his book give a good alternative to current MVC frameworks that use a bunch of POJOs with getters/setters, and rather using some form of a builder pattern implementation. He also mentions that getters and setters are OK in some cases (at least in his book he does).
  10. Re: programming language?[ Go to top ]

    Hi Ilya
    Again with this sell a book crap. Cedric, how many times can authors tell you that they make minimum wages on computer books and most still think that they actually try to sell them.
    I don't deny that, but just because he's not going to make a lot of money with his book doesn't make his article any less of a self-promotion.
    Actually, maybe you should write a book on TestNG, I've been searching for one, though the docs are pretty good
    Thanks, I tried hard to write a good documentation, glad to see it's appreciated.
    Actually, he never says "never use them". If you actually reread the article, you'd notice that it's "most cases" that he's talking about. From an OO perspective, it's unnatural to access object state for processing, rather than asking an object to perform the task.
    I have yet to be convinced that querying state is not OO. If anything, the OO revolution taught us a simple thing: that objects are made of *both* data and behavior, and that's why OO languages that have been invented in the last three decades have always supported both. Sometimes, all you need is really getName() and nothing else. -- Cedric
  11. Re: programming language?[ Go to top ]


    I have yet to be convinced that querying state is not OO. If anything, the OO revolution taught us a simple thing: that objects are made of *both* data and behavior, and that's why OO languages that have been invented in the last three decades have always supported both.

    Sometimes, all you need is really getName() and nothing else.

    --
    Cedric
    I disagree. Yes, the languages support data and behaviour, which provides flexibility, but IMO encapsulation of the state is the key, though where overuse of getters and setters really creates an anemic domain models with a bunch of transaction scripts for processing data. It's not that we shouldn't use getters and setters (actually setters are not as bad, especially when used for dependency injection:-), it's that the overuse of getters should make you rethink your design. Why are we asking for an object state. What are we going to do with that data? Why not have the actual object peform that for us? There is never a true answer to that question, and I don't think Alan in any way is saying avoid that at all costs. He's saying, rethink your design based on true OO principles. Ilya
  12. Re: programming language?[ Go to top ]

    Why are we asking for an object state. What are we going to do with that data? Why not have the actual object peform that for us? There is never a true answer to that question, and I don't think Alan in any way is saying avoid that at all costs. He's saying, rethink your design based on true OO principles.

    Ilya
    Because no object is an island and you make no distinction between intrinsic versus extrinsic state variables. You seem to be leaving a huge consideration in OO design and that's collaboration between objects. Not all objects will, and should not, have a complete knowledge of the set of operators to affect state or the surrounding system which they themselves are encapsulated in. That's why Hollub's argument on getters and setters is facile at best.
  13. Re: programming language?[ Go to top ]

    Why are we asking for an object state. What are we going to do with that data? Why not have the actual object peform that for us? There is never a true answer to that question, and I don't think Alan in any way is saying avoid that at all costs. He's saying, rethink your design based on true OO principles.

    Ilya


    Because no object is an island and you make no distinction between intrinsic versus extrinsic state variables. You seem to be leaving a huge consideration in OO design and that's collaboration between objects. Not all objects will, and should not, have a complete knowledge of the set of operators to affect state or the surrounding system which they themselves are encapsulated in. That's why Hollub's argument on getters and setters is facile at best.
    I'm not disputing what you just said. Though your argument applies in the minority of cases at best. Let's see a real life example of good getter use and then we can discuss of whether there is a more elegant way of solving this. I truly wish that people would read his Holub on Patterns book, which shows two non-trivial applications that are wonderfuly designed with minimal use of getters and setters. Yes, he uses getters and setters, but most of those cases the getters are justified. Ilya
  14. Re: programming language?[ Go to top ]

    I truly wish that people would read his Holub on Patterns book, which shows two non-trivial applications that are wonderfuly designed with minimal use of getters and setters. Yes, he uses getters and setters, but most of those cases the getters are justified.
    I've read Alan's books in the past and I didn't like them. A little too pedantic for me. A bunch of straw man arguments to justify an opinion. As for your "builder pattern", which I believe in the example you gave is actually the Visitor pattern(I'm using the GoF definitions), Alan thinks the builder pattern and all patterns are evil: http://www.javaworld.com/javaforums/showflat.php?Board=958484&Number=1962 So I'm not sure if reading his books would add any other value than calling everything evil. I'm not sure where you're saying object collaboration is a minimal use case set. Unless the applications you design are one monolithic object that encapsulate the entire knowledge space of a problem domain -- collaboration is the whole point of OO(Partition a problem domain into discreet objects to perform tasks and operate on state/state transitions). And once again, I don't think getters and setters expose the implementation details of an object as Alan states, internally, you still don't know how that state is maintained. You're only providing a facet to extract or push state into or out of the Object's context. Just because a method doesn't beging with get* or set* doesn't mean that it's not exposing or extracting state.
  15. Re: programming language?[ Go to top ]

    I truly wish that people would read his Holub on Patterns book, which shows two non-trivial applications that are wonderfuly designed with minimal use of getters and setters. Yes, he uses getters and setters, but most of those cases the getters are justified.


    I've read Alan's books in the past and I didn't like them. A little too pedantic for me. A bunch of straw man arguments to justify an opinion.
    Well, we disagree on that. I only read one of his books and it's a classic, best book on patterns ever.


    As for your "builder pattern", which I believe in the example you gave is actually the Visitor pattern(I'm using the GoF definitions),
    No, it's a Builder pattern. You have a generic builder interface that is used for an object to build itself. There is no visiting within the object graph.
    I'm not sure where you're saying object collaboration is a minimal use case set. Unless the applications you design are one monolithic object that encapsulate the entire knowledge space of a problem domain -- collaboration is the whole point of OO(Partition a problem domain into discreet objects to perform tasks and operate on state/state transitions).
    Right, but operate on their own state, not a state of another object, which you basically do when you call a true getter. **Not all methods with get... are really getters** Getters are even OK to at times communicate some information, but they cannot be used to expose internal state/implementation. Ilya
  16. I'm pretty sure that's a fake[ Go to top ]

    I don't know if you're being funny, but that post in Javaworld is obviously a fake. Just a warning to anyone gullible enough to take it at face value.
  17. Re: programming language?[ Go to top ]

    He's saying, rethink your design based on true OO principles.
    You're using the same flawed premise he does. Actually, there are two: 1) There is such a thing as a "true" OO design. 2) Getters have no place in such a design. I strongly object to 2) and 1) is better left to advocacy or academic groups. I'll just reuse the same example: sometimes, a getName() is all you need. You are not going to do any further processing or invoke any complex logic, you're going to take that String and display it or store it somewhere. Objects are connected in graphs, and some of these graphs are leaves. For these, use getters, and you're not any less OO. -- Cedric
  18. Re: programming language?[ Go to top ]

    He's saying, rethink your design based on true OO principles.

    You're using the same flawed premise he does. Actually, there are two:

    1) There is such a thing as a "true" OO design.
    2) Getters have no place in such a design.

    I strongly object to 2) and 1) is better left to advocacy or academic groups.

    I'll just reuse the same example: sometimes, a getName() is all you need. You are not going to do any further processing or invoke any complex logic, you're going to take that String and display it or store it somewhere.

    Objects are connected in graphs, and some of these graphs are leaves. For these, use getters, and you're not any less OO.

    --
    Cedric
    Look, I'm not saying that this whole methodology is up for questions when you're designing in real life, but it should be at the least considered when designing your application. First, when something like getName() is needed, there is nothing wrong with exposing it, as in reality it is no longer a way to expose external state, it's a way to perform a behavior (in this case just provide data). The flaw is when your object consists of nothing else but getters and setters, though making it more or less a transfer object, with maybe minimal behavior. Again, even that in some cases is looked upon as OK, mostly when you have a very simple domain model and can get away with more or less transaction script pattern. Second, in your example above, say you need the getName() function to display in console, ok? Why not instead use... public void printYourName(PrintStream out) { out.println(this.name); } This might also not be the best way of doing so, as a better way would be to have a generic exporter interface (builder pattern), that allows you to seperate the concerns of displaying data to the implementations of the exporter... public interface Exporter { void print(String whatever); } and in your domain object... public void printYourName(Exporter exp) { exp.print(this.name); } public class ConsoleExporter implements Exporter { public void print(String whatever) { System.out.println(whatever); } } Now this is very simple, but get's quite complex when you have to export various data structures in specified formats and to various streams. And the Builder patterns (if correctly used) simplifies all of that. Ilya Sterin
  19. Re: programming language?[ Go to top ]

    Second, in your example above, say you need the getName() function to display in console, ok? Why not instead use...

    public void printYourName(PrintStream out) {
    out.println(this.name);
    Because now I'm coupling my class with PrintStream. Why would I do that? And what if I want to print to a file? To a printer? To the network? Should I add all these overloaded methods? Definitely not a good design to me. -- Cedric
  20. Re: programming language?[ Go to top ]

    Second, in your example above, say you need the getName() function to display in console, ok? Why not instead use...

    public void printYourName(PrintStream out) {
    out.println(this.name);

    Because now I'm coupling my class with PrintStream. Why would I do that? And what if I want to print to a file? To a printer? To the network? Should I add all these overloaded methods?

    Definitely not a good design to me.

    --
    Cedric
    I used PrintStream here as an interface example (though it's an implementation class). Yes, you might want to define a more generic interface, or use OutputStream. I'm not trying to show you great design here with your particular example, just a more generic, better one than asking for getName() all over the code and using it in a coupled fashion. What if the name today represents the full name, but tomorrow it represents first and last and no middle, and you have a getNameWithMiddleInitial() for that. You're basically exposing the object's implementation. The better example was the one you didn't comment on, which was the builder pattern. Cedric, I'm not arguing here on your desing decisions. Your contribution with TestNG only speaks for itself, it's the best thing in the TDD world today, and I haven't looked at the code. All I'm saying is that folks should take a bit more time looking at their design and though maybe eliminate a lot of what Alan says and I truly believe as well, is not really OO code. OO is not all about just using object oriented idioms of the language. Just because you instantiate an object and use inheritence for common behavious/state, does not make your program any more OO than a proceedural program that reuses functions for maintainability. Exposing your object's state in many cases, especially when used in a procedural fashion violates encapsulation principles. Ilya Ilya
  21. Re: programming language?[ Go to top ]

    Second, in your example above, say you need the getName() function to display in console, ok? Why not instead use...

    public void printYourName(PrintStream out) {
    out.println(this.name);

    Because now I'm coupling my class with PrintStream. Why would I do that? And what if I want to print to a file? To a printer? To the network? Should I add all these overloaded methods?

    Definitely not a good design to me.

    --
    Cedric


    I used PrintStream here as an interface example (though it's an implementation class). Yes, you might want to define a more generic interface, or use OutputStream. I'm not trying to show you great design here with your particular example, just a more generic, better one than asking for getName() all over the code and using it in a coupled fashion. What if the name today represents the full name, but tomorrow it represents first and last and no middle, and you have a getNameWithMiddleInitial() for that.
    Introducing a Name object would be a simpler solution. This debate about getters/setters is just another case of the old never dying argument over the push versus pull model. I strongly believe both have their use. In the case you described, the print logic is unrelated to the object responsabilities and doesn't belong there so a getter is a better idea IMO. Plus you have to implement some abstractions (Exporter) which are meaningless to the domain model, something I really try to avoid. But if the print logic was related to the object possessing the name attribute, I would think a getter is actually a bad idea.
  22. Re: programming language?[ Go to top ]

    Ok .... obj.printName(somwhere) is NOT better than somewhere.print(obj.getName()) Thats just crazy and I doubt Holub ever meant that. For CRUD type usecases - domain objects with getters/setters is the ONLY way to go - there just isn't another "plausable" option from an design view point. For more complex usecases e.g. bookFlight() internal sequence & any associated CRUD must be encapsulated under the hood of that method/object.
  23. Re: programming language?[ Go to top ]

    Ok ....

    obj.printName(somwhere)
    is NOT better than
    somewhere.print(obj.getName())

    Thats just crazy and I doubt Holub ever meant that.

    For CRUD type usecases - domain objects with getters/setters is the ONLY way to go - there just isn't another "plausable" option from an design view point.

    For more complex usecases e.g. bookFlight() internal sequence & any associated CRUD must be encapsulated under the hood of that method/object.
    No, it's not better in this trivial example, just like most java web frameworks are not better than RoR in trivial examples, the issue comes when building large systems with unpredictable change. Imagine a currency class that outputs a float or double with it's getAmount method. The currency is printed as... Amount: 20.00 Tomorrow, we need to display the currency symbol, yet another state maintained within the currency object. Changing the return type to String or something else and appending a symbol, so that it's rendered correctly in all print implementations will break any implementation that uses it for calculations as well. Plus changing all print methods to now output the currency, will require to change the signature of print method or overload it, which if this is a generic method contained in some helper class, would break other usage of it where that symbol is not required or make you refactor large portions of code, where this method is to be used in it's new signature. If you contain the knowldege of the rendition in the object itself, you would simply change the objects printMe method and be done with it, since it prints to an interface, all request to print currency would now be changed and the object will be consistenly rendered throughout. Again, this is a very rudimentary example of it and you might argue that having some other class that takes care of printing in a smart way would do, so a more complex example is needed which I care not to think of right now, nor explain. The basic idea is to limit communication as much as possible. Yes, it's not doable 100% in a large system implementation, but what helps is to think in these terms and though let it guide your domain design.
  24. Re: programming language?[ Go to top ]

    Tomorrow, we need to display the currency symbol, yet another state maintained within the currency object. Changing the return type to String or something else and appending a symbol, so that it's rendered correctly in all print implementations will break any implementation that uses it for calculations as well. Plus changing all print methods to now output the currency, will require to change the signature of print method or overload it, which if this is a generic method contained in some helper class, would break other usage of it where that symbol is not required or make you refactor large portions of code, where this method is to be used in it's new signature. If you contain the knowldege of the rendition in the object itself, you would simply change the objects printMe method and be done with it, since it prints to an interface, all request to print currency would now be changed and the object will be consistenly rendered throughout.
    I can't believe that after all the counter-examples that have been given to you, you still think that embedding the display logic inside the object is a good idea, but since the right solution is exactly what you are trying to argue against, I can see why you are doing that. Problem: we have an object that can be displayed in many different ways, most of them we don't even know yet (printer, network, morse code, who knows?). Solution: expose the various components of the object in little pieces so that future displayers can do the right thing. In this particular case, you would provide getters for "getIntegerPart()", "getFloatPart()", "getCurrencySymbol()" and that's it. You're now guaranteed that your object will be displayable on anything and you will probably never have to modify it again. -- Cedric
  25. Re: programming language?[ Go to top ]


    Tomorrow, we need to display the currency symbol, yet another state maintained within the currency object. Changing the return type to String or something else and appending a symbol, so that it's rendered correctly in all print implementations will break any implementation that uses it for calculations as well. Plus changing all print methods to now output the currency, will require to change the signature of print method or overload it, which if this is a generic method contained in some helper class, would break other usage of it where that symbol is not required or make you refactor large portions of code, where this method is to be used in it's new signature.

    If you contain the knowldege of the rendition in the object itself, you would simply change the objects printMe method and be done with it, since it prints to an interface, all request to print currency would now be changed and the object will be consistenly rendered throughout.

    I can't believe that after all the counter-examples that have been given to you, you still think that embedding the display logic inside the object is a good idea, but since the right solution is exactly what you are trying to argue against, I can see why you are doing that.

    Problem: we have an object that can be displayed in many different ways, most of them we don't even know yet (printer, network, morse code, who knows?).

    Solution: expose the various components of the object in little pieces so that future displayers can do the right thing.

    In this particular case, you would provide getters for "getIntegerPart()", "getFloatPart()", "getCurrencySymbol()" and that's it. You're now guaranteed that your object will be displayable on anything and you will probably never have to modify it again.

    --
    Cedric
    Cedric, again, the embed the printing knowledge only applies to the most simple examples. The best way is to privide a Builder interface. By exposing the information of the object (which is again OK in some cases), you are exposing the implementation detail, though the objects implementation is now tightly coupled to what ever code is using it. I don't know why you can't see it as violating the most simple OO principle "Don't expose your implementation details".
  26. Re: programming language?[ Go to top ]

    Cedric, again, the embed the printing knowledge only applies to the most simple examples. The best way is to privide a Builder interface. By exposing the information of the object (which is again OK in some cases), you are exposing the implementation detail, though the objects implementation is now tightly coupled to what ever code is using it. I don't know why you can't see it as violating the most simple OO principle "Don't expose your implementation details".
    This is getting out of hand. So basically, the best way to do something is this builder interface way, although it's OK to do it some other way in other cases. How is anyone supposed to follow that? Let's face it, Cedric's way of building it is much simpler. Why would I want to write all that extra code and outsmart myself to just print currency. Let's use his example for a moment. Tell me exactly why it's bad to expose the fact that the currency has multiple parts?? The caller can determine how to display it for their system. In some systems it may display the currency symbol and in others it might not (for example, in small display devices). Where does that logic belong? In my mind you have a currency class that contains logic for dealing with currencies (just computations/manipulations, not display) along with the currency getters for the data and maybe some other getters for determining if the data in question has certain characteristics of interest and then you have a set of classes that knows how to display it in different ways. Those implementations can then be paired up with an appropriate display class (i.e. Swing, Web, etc.). The wiring is another story because depending on your target audience you might need to pair these classes up based on the locale of the user or some other criteria. Data has to be retrieved from the object somehow and I don't really want my main class that has the data (in this example) needing to know about other interfaces/classes in my system. What about pushing the data over the wire? Or being sent via an e-mail? I'd much rather extract the data and let the caller worry what it's going to be used for than having the currency class in this example needing to know about something else. To me that's just bad design. How is this not OO? And how would you build this in Holub's view of the world? I'm always up for seeing new ways to do something but I just don't see any improvement in the approach you've advocated over the one I would use above. Maybe I'm misunderstanding your approach but nothing leads me to believe that just yet. -Mike
  27. Re: programming language?[ Go to top ]

    This is getting out of hand.
    Not really, I think it's a productive discussion. I respect Cedric greatly for his contributions, though I might disagree with him on some things:-)
    So basically, the best way to do something is this builder interface way, although it's OK to do it some other way in other cases. How is anyone supposed to follow that?
    Easily, patterns are not always the solution. For trivial apps, you do what works. Transactions script patterns works fine as well, just don't use it in an application that has a rich domain model. So yes, if your application basically has a bunch of value objects, feel free to expose its state. But the trend I'm seeing, is that we are now in this POJO development world, where your domain is basically build with POJOs and then you have a bunch of frameworks gluing things together by exposing the state of each tier/objects. Some use reflection for various things, though allowing not to expose public getters, but at the same time, they are still accessing the state. I just think that it's the quickest/easiest way of integrating tiers, so we chose it. Not that they are not appropriate in some cases.


    Let's face it, Cedric's way of building it is much simpler.
    It's also alot simpler to implement the transaction pattern, then a fully blown domain model. So why don't we go back to writing procedural apps.
    Why would I want to write all that extra code and outsmart myself to just print currency. Let's use his example for a moment. Tell me exactly why it's bad to expose the fact that the currency has multiple parts??
    You're going back to the currency thing, as if I gave you a real world example, it was a small sample. If that's all there was to it, then you should care less about how to implement it, there are multiple ways. But when you start dealing with larger domain modesl with hudreds of such concerns, you want to find a generic way of doing this, and it's too popular these days to just say, let's not define collaboration and encapsulation of object's state, rather we'll expose it.
    The caller can determine how to display it for their system.
    That's considering that the implementation didn't change, like getCurrency changing from double to String return value to facilitate the currency sign. Again, very trivial example. You can argue that getCurrency is an interface, but in most cases it's not defined that way and getters on each field within the class is basically the violation of encapsulation. Again, there were plenty of real world situations that I've worked with that allowed me to chose such an approach as well. All I'm trying to say (and I'm sure Holub as well), is that if we take more time to truly design an object model, that hides it's implementation, we'll be better of in the long run. No solution applies to each case.
    In some systems it may display the currency symbol and in others it might not (for example, in small display devices). Where does that logic belong?
    In the business object or some interface specifically design for such purpose (i.e. builder). If you couple the tier that is now using the object to get it's internal state and represent it in some way, you have less flexibility in changing the object's internal state and though you just tightly coupled your implementation.
    How is this not OO? And how would you build this in Holub's view of the world?
    It's not Holubs view, it's general OO design.


    I'm always up for seeing new ways to do something but I just don't see any improvement in the approach you've advocated over the one I would use above. Maybe I'm misunderstanding your approach but nothing leads me to believe that just yet.

    -Mike
    So am I, I'm always up for new ideas. I'm not advertising Holubs book here, especially not the compiler one:-) But read Holub on Patterns for a more detailed explanation (at least better than I can do right now while fighting a cold). You can also just read his articles from his site. I think the book repeats alot of the material, though it applies it in a more practical way. Ilya
  28. Re: programming language?[ Go to top ]

    I set out writing a class to mock the silliness of Cedric's slavish devotion to setters, but instead, in the spirit of my xml example above, uncovered an good argument to use setters -- you'll never know when a public String will need extending, and you'd hate to have to rewrite String name="Bob"; from scratch. NameBean extends ConfigurableBean implements Configurable { private String name; private Configuration config; NameBean(Configuration config) { this.config = Configure(config) } protected void Configure(Configuration config) { try{ ConfigureBean.Configure(this.config); } catch(Exception e) { this.config = config; } return config; } @configurable public void setName(String name) extends configurableSetter { if (! name) { if (ConfigurableBean.parameterIsNotSet(config.name)) { config.name = ""; } name = config.name; } else { this.name = name; } } @configurable public string getName(String defaultName) { if (defaultName == config.name) { throw RespecifyingSameDefaultNameException; } else { if (! name) { return config.name; } else { return name; } } } }
  29. Re: programming language?[ Go to top ]

    I set out writing a class to mock the silliness of Cedric's slavish devotion to setters
    I'm not quite sure where you got that from since I haven't said a word about setters yet, but since you're challenging me, I'll list two use cases that can't exist without setters: - Dependency injection - Object pooling -- Cedric
  30. Re: programming language?[ Go to top ]

    From an academic standpoint, Alan's Book(s) are probably best suited for undergraduate work, where the emphasis is on the how of a potentially few relevant but necessary compiler theories. The "Red dragon book" is as noted a classic, and covers a much greater range, scope and depth of theoretical compiler theories. Therefore, practicality would be in the eye of the problem solver. (Personally, I've never opened either book after leaving college!) The few references that I have looked at regarding DSLs start with lex, yacc, and various Unix tools. I would guess that ADA didn't succeed as a language b/c the domain was too large. Then, Ruby gets mentioned. Are there any other use cases for DSLs right now other than the tooling examples that Gavin mentioned?
  31. Re: programming language?[ Go to top ]

    Alan likes to write sensationalistic articles filled with extreme statements in order to either:
    - Get readership.
    - Sell a book.

    Today, he's doing the latter, and he's as unconvincing as he's ever been (probably only topped by his nonsensical "never use getters nor setters" article linked above).
    Agree 100% Alan makes controversial, incorrect and extreme statements once in a while. I dont know what is he upto today, but he is not selling the book. I searched Amazon and that book was written in 1990/1994 and is out of print. So he is definitely not selling the book. Nonetheless Alan's statements are not right, dont take realities and into account and are extreme. They would provoked the same reaction even if they were made in his personal blog. And definitely dont fit on the SD Times editorial at all.
  32. Re: programming language?[ Go to top ]

    Yeah, right. Buy his book and you'll learn how to write a compiler in... C. Now, that's going to help.
    Learning how to write a compiler in any mainstream language will help anyone with understanding the issues involved. One could argue that learning to write a compiler in a functional language will not help as much as doing the same using a 'regular' programming language, but that's not the case here. If you learn to do it in C you can then do it in both Java and Ruby for instance. I does help.
  33. Re: programming language?[ Go to top ]

    First of all, Alan is the leading authority on Object Oriented design and programming.
    Yeah, right. Mr "I do not have patience for those who cannot build a compiler". And I, do not have patience for those attention-starved, pontificating blowhards that have nothing better to do than write useless and self-congratulating articles. I (and certainly most of the developers & architects coming to TSS), do not need Mr Holub to educate me on the improper use of XML. Because pretty much everything has been already said, discovered, and discussed on the subject already. And if Mr Holub meant that XML is often misused, then the title of his article should convey that idea, instead of using catchy and extreme words. This is the programming world, not Fox News.
  34. Re: programming language?[ Go to top ]

    First of all, Alan is the leading authority on Object Oriented design and programming.


    Yeah, right.
    Ah, he pretty much is. Read his Holub on Patterns book and let me know what you think after. It's a highly opinionated book, but he backs up every claim with real life examples in code:-)


    Mr "I do not have patience for those who cannot build a compiler".

    And I, do not have patience for those attention-starved, pontificating blowhards that have nothing better to do than write useless and self-congratulating articles.

    I (and certainly most of the developers & architects coming to TSS), do not need Mr Holub to educate me on the improper use of XML. Because pretty much everything has been already said, discovered, and discussed on the subject already.

    And if Mr Holub meant that XML is often misused, then the title of his article should convey that idea, instead of using catchy and extreme words. This is the programming world, not Fox News.
    Fox News? Why did you have to use my favorite station? Why couldn't you compare it to MSNBC, CNN, etc... Why is everyone picking on Fox? :-)
  35. I couldn't help myself on thinking how it could look on my favourite news... :) My opinion: XML is very known LANGUAGE. As its name says, it's not a programming language, nor a data language... it's simply extensible MARKUP language. WE extend it to be a programming language or a data language, or a workflow language... Allan has a good point, but our fellow Pascal Gehl hit the spot with "My boss will like that..." XML is 'verborragic', but, formatted, it's clear and intuitive, very known in the industry. This characteristic certainly has value. Let's see, if I have an application that needs it's configuration change on runtime by someone who may not know java, XML might be a choice to work with. On the other hand, Mentawai's approach is very good if the person making the configuration is related to java. They are all tools. We use them as we see fit.
  36. I'm a very big proponent of XML, but when used correctly. I've written numerous resources on it and honestly think that it's underused in scenerious where it should be utilized. But I completely agree with Holub, that it's being abused in the configuration world these days. Though we're all used to it and almost expect it these days. It's fine for configuration data and to possibly persist readable state, but definitely not to be abused as say ant uses it for what is no longer a build configuration, rather a build script. Ilya
  37. Re: programming language?[ Go to top ]

    First of all, Alan is the leading authority on Object Oriented design and programming.


    Yeah, right.


    Ah, he pretty much is. Read his Holub on Patterns book and let me know what you think after. It's a highly opinionated book, but he backs up every claim with real life examples in code:-)
    Fox News? Why did you have to use my favorite station? Why couldn't you compare it to MSNBC, CNN, etc... Why is everyone picking on Fox? :-)
    I read Hollub's book on patterns some time ago, and believe it is pretty decent. But I also believe that being a "leading authority" goes a bit further than writing one decent book. But that's just my opinion... Me picking on Fox News? Hell no. I only suggested that Mr Holub's taste and talent for attention-grabbing titles would be much better put to use in some style of journalism than in the programming world ...:-)
  38. Re: programming language?[ Go to top ]

    I (and certainly most of the developers & architects coming to TSS), do not need Mr Holub to educate me on the improper use of XML. Because pretty much everything has been already said, discovered, and discussed on the subject already.
    That's right! We improperly use XML just fine without any education, thank you very much!
  39. Re: programming language?[ Go to top ]

    In any case, XML is not the problem, it is how its used.
    Agreed. XML has its uses. However, it IS overused and IS NOT an efficient means of sending data around, IMO. Lets not forget that XML was created to make data self-descriptive. However, in all of XML's applications, how often do we really need to actually open XML content up in a text editor to look at it with our own eyes?
  40. For what it's worth, Compiler Design in C has been out of print for many years now, and I certainly don't get any money when you buy a used copy on Amazon. The only reason I brought it up in the article was that it's one of the few books on compiler design (of which I'm aware, at least) that presents the entire source code for a nontrivial compiler. In any event, I probably made on the order of $0.25/hour on the thing. Sheesh! The reason I wrote the article is that I think that XML is used inappropriately in pretty much all but the hierarchal-data-representation applications for which it's actually designed. Most of the comments that I'm reading here say that XML is okay for applications where XML is appropriate, and I certainly have no problem with that point of view. I do have a problem with things like JSTL (to use one of the most eggregious examples), which attempts to transmogrify XML into something that it's not. You wouldn't consider implementing a large-scale enterprise application in Assembly Language becuase it's an innappropriate language for that particular application. That is, there are no keywords or other syntactic structures that abstract essential concepts or operations in the problem that you're trying to solve. So, what is it about XML that would make it an appropriate language for anything other than hierarchal-data description? Also, saying that XML is "familiar," and thus easy to grasp, is nonsense. That's like saying that Scheme is familiar to a C programmer because the keywords are in English. Angle brackets are familiar, but the syntax and semantics of an XML-based schema is unique to that schema, and is probably harder to understand (and to learn) than would be the syntax of a purposed high-level language that focused on solving the problem at hand.
  41. Also, saying that XML is "familiar," and thus easy to grasp, is nonsense. That's like saying that Scheme is familiar to a C programmer because the keywords are in English. Angle brackets are familiar, but the syntax and semantics of an XML-based schema is unique to that schema, and is probably harder to understand (and to learn) than would be the syntax of a purposed high-level language that focused on solving the problem at hand.
    Sounds like you have fodder for a new article giving us all an example of the benefits of DSL compilers over XML. XML is an intermediate representation of data, primarily hierarchal but not necessarily as you are asserting. Granted there are abuses of XML but the same could be said of DSL. You still need a "compiler/parser" on the other end of a converstation to make sense of the markup. It's been awhile since I've dealt with compilers but don't compilers/parsers also store intermediate structures of data and instruction sets? To suggest that compilers should be written instead of using a relatively standard document format is a step backwards akin to the proprietary EDI days.
  42. Most of the comments that I'm reading here say that XML is okay for applications where XML is appropriate, and I certainly have no problem with that point of view. I do have a problem with things like JSTL (to use one of the most eggregious examples), which attempts to transmogrify XML into something that it's not.
    Well, that makes sense. The problem is that before JSTL there was scriptlets, and all agreed that scriptlets were bad - even though scriptlets are constructs in a real programming language compiled by a real compiler. I guess it is a matter of taste, but I prefer JSTL:s tag based syntax to scriptlets, and I have a feeling that theres a lot of people who agrees with that.
  43. Re: programming language?[ Go to top ]

    he is not miss informed, XML is not a programming language, but many of the tool builders does not seem to know it, for example, if you use ANT, you use XML as a programming language when writing the build.xml, ... this is what he talked about, the misuse of XML.
  44. Re: programming language?[ Go to top ]

    Read the article. The synopsis above is quite misleading. Holub never says it's a programming language, quite the opposite in fact. He said is should never be used as a programming language.
  45. Re: programming language?[ Go to top ]

    Obviously this guy is "misinformed". XML is not a programming language. Maybe he got confused and thought that XPATH is programming.

    If anything, I'd say XML is like a database and XPATH/XQUERY is equivalent to SQL in terms of data access.

    Oh well. The guys is still learning what XML is for.
    How about BPEL? I don't know very much about it, but my impression is that it is very close to a programming language in XML.
  46. Go **** yourself, Lubby!
  47. Since when XML is a programming language, it never was, it appears that people do not understand about computer science anymore. XML never is a programming language, the design of XML is to transfer data (a job that does well, with certain limitations). So you can always put a square peg in a round hole (depends on the size of the hammer)
  48. XML is a conversion tool[ Go to top ]

    We use XML mainly as data format conversion tool. For example how to convert data format of DB2 to oracle data format.So I think XML is not a a programming language. Java Tutorial
  49. Re: Allen Holub: Just Say No to XML[ Go to top ]

    Old school...but he has a point. He's probably just a little too extreme. I wouldn't say everyone needs to know how to write a compiler. But knowing how to write a good parser in an important skill. By good parser, I don't mean something hacked together with regular expressions and string compares. I think knowing how to write a good interpreter is useful, but not really essential. Not many people need to know how to write compilers.
  50. Re: Allen Holub: Just Say No to XML[ Go to top ]

    XML is an overly verbose way of communicating information. If I was designing a general syntax for transporting information it would be more terse than XML. That said, XML is here. You can use it to convey any information you want (including instructions to computers if you really want). And there are lots of tools around to manipulate it. So for most people it is now the easy choice. I hope to continue to enjoying Allen's bold contentious statements: Why getter and setter methods are evil.
  51. Bad Example[ Go to top ]

    XML is an overly verbose way of communicating information. If I was designing a general syntax for transporting information it would be more terse than XML.

    That said, XML is here. You can use it to convey any information you want (including instructions to computers if you really want). And there are lots of tools around to manipulate it. So for most people it is now the easy choice.

    I hope to continue to enjoying Allen's bold contentious statements: Why getter and setter methods are evil.
    His getter and setter article uses a really bad example. It says Swing/AWT is not a UI Layer but an abstraction. Depending on his definition of UI Layer he might be right but never the less it is only ONE form of presentation layer; other forms of presentation layer are jsp/jsf/j2me. He is advocating we put UI Layer abstraction into the business entity. But his UI layer abstraction (in his mind Swing/AWT "abstracts" the native windowing system, hence UI abstraction) does not abstract the presentation layer! The moment you want to change to other presentation formats, i.e. jsp/jsf/j2me, you have to reengineer the business entity.
  52. Re: Allen Holub: Just Say No to XML[ Go to top ]

    Well, 99% of the time XML is not used as a programming language, but rather as configuration or data format. Compiler construction has no bearing on that. Sure, you can use a dsl for configuration, but there is no way to make a general conclusion that it is always to prefer over some configuration file format. Also, the statement in the article about runtime performance seems pretty uninformed when it comes to the examples given - ant, testng, even jsf. JSF might have a reputation for being a tad sluggish, but I can assure that it has nothing to do with the time needed to parse the page source...
  53. Re: Allen Holub: Just Say No to XML[ Go to top ]

    JSF might have a reputation for being a tad sluggish, but I can assure that it has nothing to do with the time needed to parse the page source...
    I still haven't seen any real proof of this "reputation". From my experience doing consulting and mentoring with different JSF development groups, the apps aren't any more sluggish than web apps built with other frameworks. There are now quite a few public JSF sites, and sites like JSF Central and the Infact Book Search don't seem slow to me either... Kito D. Mann (kmann at virtua dot com) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  54. Re: Allen Holub: Just Say No to XML[ Go to top ]

    JSF might have a reputation for being a tad sluggish, but I can assure that it has nothing to do with the time needed to parse the page source...


    I still haven't seen any real proof of this "reputation". From my experience doing consulting and mentoring with different JSF development groups, the apps aren't any more sluggish than web apps built with other frameworks.
    That would depend a lot on which "other framework" you mean, but if you would compare the work done by the framework between for instance struts and "any" jsf implementation, then the jsf implementation will do more work. As you know. If that translates to sluggish or not kind of depends on how picky you are. For a real world application actually doing something, like querying a db or whatever, the extra time spent might not be noticeable. Anyhow, off-topic.
  55. Ant and XML[ Go to top ]

    Also, the statement in the article about runtime performance seems pretty uninformed when it comes to the examples given - ant, testng, even jsf.
    Well, James Duncan Davidson admitted that, in hindsight, XML wasn't the best choice for ANT: http://web.archive.org/web/20040602210721/x180.net/Articles/Java/AntAndXML.html
  56. Re: Ant and XML[ Go to top ]

    Also, the statement in the article about runtime performance seems pretty uninformed when it comes to the examples given - ant, testng, even jsf.


    Well, James Duncan Davidson admitted that, in hindsight, XML wasn't the best choice for ANT:

    http://web.archive.org/web/20040602210721/x180.net/Articles/Java/AntAndXML.html
    Ah, good one. Definitely agree. Ant is good (maven is better IMO:-), but would of been better served by a simple DSL.
  57. Re: Ant and XML[ Go to top ]

    James Duncan Davidson admitted that, in hindsight, XML wasn't the best choice for ANT:

    http://web.archive.org/web/20040602210721/x180.net/Articles/Java/AntAndXML.html


    Ah, good one. Definitely agree. Ant is good (maven is better IMO:-), but would of been better served by a simple DSL. DSLang ( do not like DSL acronim becuse DSL is what I use to connect to Internet ) is the way to go, but those Domain SLangs will not catch till tools like MPS will not gain wider adoption. XML in many cases used as poor's man DSLang when accompanied by schema or DTD. Schema and DTD aware editors help to navigate XML maze, but cannot provide the same level of support as decent IDE.
  58. Re: Allen Holub: Just Say No to XML[ Go to top ]

    Well, 99% of the time XML is not used as a programming language, but rather as configuration or data format. Compiler construction has no bearing on that. Sure, you can use a dsl for configuration, but there is no way to make a general conclusion that it is always to prefer over some configuration file format.

    Also, the statement in the article about runtime performance seems pretty uninformed when it comes to the examples given - ant, testng, even jsf.

    JSF might have a reputation for being a tad sluggish, but I can assure that it has nothing to do with the time needed to parse the page source...
    Configuration data *is* programming. You are assigning variables. Someone mentioned earlier that XSLT had loops and conditional logic. I thought to myself, there is only one more element needed for a turing complete language: Variables. And there it is in XML configuration files. Another example listed is:
    Most programmer know enough about compiler theory as a heart surgeon who only knows that the heart pumps blood. If you knew that a grammar was:

    SENTENCE: PERIOD

    She codes beautifully.

    Then why would you appreciate tagging it up like:


    She
    plays
    beautifully
    .


    when you can write a simple grammar?

    However, DTDs and Schemas qualify as sufficient grammar.
    The real problem is that the configuration structure we are given by lazy coders isn't the one listed above (if only it were) but rather more like: codes 1
  59. As far as I can tell, it’s because many so-called programmers just don’t know how to build a compiler.
    In my opinion, developers shouldn't care about such a low-level stuff. That's the reason we're using Java! Anyways, annotations should reduce the use of XML, more and more...
  60. An advertisement?[ Go to top ]

    After reading the article,I have an idea :he is making an advertisement. Xml is a good tool,especally in configration for application. But there is a precondition,it should be organised in a good and readable structure,else it will be every ugly. Sometimes,xml is not a good payload.It contains much tags which have less relation with datas.We just need its structure. Why not create a new language like javascript which can be sent from one side written in the language in text mode and then run in another side written by the language too? just a structure,not many tags,as simple as it can? Remember a good compiler or a parser for it.
  61. Don't know grammar[ Go to top ]

    Most programmer know enough about compiler theory as a heart surgeon who only knows that the heart pumps blood. If you knew that a grammar was: SENTENCE: PERIOD She codes beautifully. Then why would you appreciate tagging it up like: She plays beautifully . when you can write a simple grammar? However, DTDs and Schemas qualify as sufficient grammar.
  62. Re: Allen Holub: Just Say No to XML[ Go to top ]

    The beauty of XML is that it is recognised by many platforms and is basically ..i may be repeating others.. a common standard for storage and transportation of data across various platforms and languages. So eliminating XML would take some time.
  63. the man is right escpecially about control-flow language. My last project was one without XML and I enjoyed it because it was so much easier to debug and keep track of things. Now i am back on jsf with jsp and hibernate and frustrated most of the time again. The hibernate mappings are not so bad but the jsp is really really bad. I really dont understand why most people think that it is easier to define a view in XML.
  64. Ok, so XML is not appropriate to everything. That doesn't mean that it's not appropriate for ANYTHING. Jelly is clearly an example of taking XML too far (into being an actual programming language). BUT that's the exception that confirms (actually: makes obvious the limitations of) the rule. Are DSLs any simpler? Absolutely not. I'm personally able to build a decent enough compiler for a DSL. But does that mean that person who'll follow me will have that skill, which is currently quite rare? I doubt it. So, no one to maintain my little compiler after I've moved on. I'm sure my boss would be very happy about that. Also, think about the fact that we do, occasionally, make mistakes; what do you do when you find a significant flaw in your DSL? Do you have the resources to create the tools required to update the existing DSL-based "programs"? Or will you have to manually go through all these program bits and modify them one by one? XML may not be perfect, but it has some serious advantages; not the least of which is its stability. AND the fact that highly optimized parsers exist for it (it would take me years to build a parser that optimized for anything but the simplest of DSLs). AND the fact that it has the mindshare. AND the fact that pretty much everything supports it. AND... So you may be a fan of DSLs; I admit the whole concept is very cool. But they won't displace XML anytime soon...
  65. For what it's worth, the complete text of the article said that XML is just fine as a data-description language. My point was that it's inappropriate to use it in place of a real programming/scripting language.
  66. Ok, so XML is not appropriate to everything. That doesn't mean that it's not appropriate for ANYTHING. Jelly is clearly an example of taking XML too far (into being an actual programming language). BUT that's the exception that confirms (actually: makes obvious the limitations of) the rule. Are DSLs any simpler? Absolutely not. I'm personally able to build a decent enough compiler for a DSL. But does that mean that person who'll follow me will have that skill, which is currently quite rare? I doubt it. So, no one to maintain my little compiler after I've moved on. I'm sure my boss would be very happy about that. Also, think about the fact that we do, occasionally, make mistakes; what do you do when you find a significant flaw in your DSL? Do you have the resources to create the tools required to update the existing DSL-based "programs"? Or will you have to manually go through all these program bits and modify them one by one? XML may not be perfect, but it has some serious advantages; not the least of which is its stability. AND the fact that highly optimized parsers exist for it (it would take me years to build a parser that optimized for anything but the simplest of DSLs). AND the fact that it has the mindshare. AND the fact that pretty much everything supports it. AND... So you may be a fan of DSLs; I admit the whole concept is very cool. But they won't displace XML anytime soon...
  67. broad?[ Go to top ]

    he did set up the context of his article right at the beginning: "XML is perhaps the worst programming language ever conceived. I’m not talking about XML as a data-description language, which was its original design. I’m talking about perverting XML for programming applications. It’s inappropriate to use XML as a scripting language (e.g., ANT), a test-description language (e.g., TestNG), an object-relational mapping language (e.g., Hibernate, JDO), a control-flow language (e.g., JSF), and so forth. These sorts of XML “programs” are unreadable, unmaintainable, an order of magnitude larger than necessary, and audaciously inefficient at runtime." i don't disagree with you at all about overly broad statements but in this case the author has scoped his complaint. while i may not completely agree with him he certainly has a point. ANT is a scripting language, O-R mapping could be so much more flexible if it were scripted instead of static xml data, JSF and work flow defintions as XML make them inflexible, etc, etc.
  68. overly broad statements[ Go to top ]

    Yep. It's an overly broad statement. It reminds me of all the hysteria that was created when a bone-head said that "IT doesn't matter anymore", or something to that affect. What a joke!
  69. Use JavaCC or ANTLR
  70. Re: Allen Holub: Just Say No to XML[ Go to top ]

    I take everything Holub says with a huge grain of salt. I read SD Times regularly, and his column usually has severely misinformed and illogical content. I suppose he exagerates his points intentionally in order to incite a reaction, but I find that this tactic tends to make him look foolish, given the shaky basis of his arguments. That being said, we are definitely in a state of XML overload. But while Ant may be using XML as a scripting language (for better or worse), I don't think that JSF's navigation rules or Hibernate's mapping files are in the same camp. You can't call them "progams". Kito D. Mann Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  71. I am about to create some functionality where prodecures and policies are creating by and end user and stored in the db. I was going to use XML because it is human-readable, intuitive, and there are already mature XML handling tools out there I can use. If there is a better way to do this, I am open to it. But I admit I don't understand why the author claims that I shouldn't use XML, but should use some custom compiler. If anyone would like to help me out here, I'd appreciate it.
  72. Re: Allen Holub: Just Say No to XML[ Go to top ]

    To actually understand the argument that is being made in this article you have to replace every occurrence of the word "compiler" with the correct term: "parser". Then the article makes sense and is substantially correct, though it's idea is certainly not novel. The fact is that Ant scripts and Hibernate mappings and jBPM process definitions - and even stuff like configurations - *would* be more cleanly expressed using non-XML-based DSLs. However, the proffered explanation for the use of XML-based DSLs is in fact not correct or only partially correct. It is not (only?) because we don't know how to write parsers that we use XML for stuff. For example, Hibernate uses a sophisticated 3-stage ANTLR-based parser for the query language, so clearly the Hibernate team had access to a lot of knowledge about parsers (in the person of Joshua Davis). So why doens't Hibernate have a non-XML-based mapping document format? Well, the first reason is that as soon as you use an XML-based DSL you get things like code completion and syntax validation (a) for free and (b) in any IDE environment. To build this functionality for a non-XML-based DSL, for all the IDEs in common use in the Java world would be prohibitively expensive. Alternatively, expecting Hibernate users to *memorize* the syntax of a on-XML-based mapping DSL is unrealisitic - there are simply too many complex constructs there. So the value of XML here is the tooling. The second reason is simply that annotations provide a better way, at least for this specialized case (they wouldn't work for Ant, however). Note that there are currently efforts underway (eg. Jetbrains) to create development environments where it is easy to define new DSLs and that the DSL is fully understood by the tooling. This is pretty interesting. Perhaps even more interesting would be an eclipse DSL editor plugin which could take an ANTLR grammar and provide autocompletion and validation. ie. do what XML editors do for DTDs or schemas with a grammar. That would be Cool :-)
  73. DSLs and Parsers and IDEs[ Go to top ]

    Perhaps even more interesting would be an eclipse DSL editor plugin which could take an ANTLR grammar and provide autocompletion and validation. ie. do what XML editors do for DTDs or schemas with a grammar. That would be Cool :-)
    I tend to disagree with Gavin on a lot of things, but I think he's just about spot on here. I think an impending "revolution" will be a standard for describing DSLs such that tools (IDEs in particular) can provide good support for them. I think the primary problem with that is that good tool support has to go beyond syntax and into semantics. A grammar only buys you syntax, and semantics are complicated.
  74. Good subject, poor body[ Go to top ]

    I think that subject "Just Say No to XML" is good, but the body of the article fails to deliver the right message. I think that use of XML has been stretched beyond its usefull boundaries and that in many cases it makes software more difficult to configure, read and understand (which is what XML was supposed to alleviate). Holub goes on to talk compilers vs. parsers which - in my humber opinion has least to do with the issues related to over-use of XML. Except for use XSLT-style of development no one is really confusing XML with a programming language. We can stretch that case to say that TestNG, Maven, ANT etc. are treating it that way, but we can also easily argue otherwise. My eye also happend to catch that plug for Holub's book. I guess we all need to pay the bills.
  75. Re: Allen Holub: Just Say No to XML[ Go to top ]

    Hm - I would argue that for every hour you spend creating your own proprietary DSL and parser you subject every one of your users to learn a new grammar/language while they already know how XML and how to navigate it. While in some specific cases it has its place, I would think the approach of creating grammars and parsers for a problem domain this day falls into the NIH category of software myths.
  76. XML should be platform independent data, and nothing more than that. It is huge, it is akward, and is annoying, but that what it is. DATA. I think XML should not be used for any kind of configuration at all. I think XML should not be used to model business logic. I was saying that one year ago here: http://www.javaworld.com/javaworld/jw-07-2005/jw-0718-mentawai.html A lot of people are using mentawai (http://www.mentaframework.org/) just because it has ZERO xml and it is as simple and productive as it could be. Sergio
  77. I think XML should not be used for any kind of configuration at all.
    Yet, there are dozens of frameworks (and a few of them very successful) that have their foundation set on XML files. Not only do these frameworks do the job, but developers who use them seem fairly happy. Therefore, I think that your claim is wrong, but I'm curious: if it's not XML, how would you suggest we describe data that can be changed without requiring compilation? Because this is something I've seen in many people who criticize XML: they either don't suggest an alternative, or they suggest something worse (like Holub did). -- Cedric
  78. Not only do these frameworks do the job, but developers who use them seem fairly happy.
    I don't think so. Open your eyes and see that a huge amount of people are migrating to Ruby and RoR because they are tired of Struts, WebWork and SpringMVC. They say they are easy and do the job, but in practice the story is different.
    Therefore, I think that your claim is wrong, but I'm curious: if it's not XML, how would you suggest we describe data that can be changed without requiring compilation?
    You definitely need to take a look on Mentawai, specially the FAQ session in the cover page (http://www.mentaframework.org). I will save you some time and post it here:
    * Isn't it wrong to place configuration into code? Yes! Mentawai does not put configuration into code at all. Although Mentawai configuration is done in Java, it is totally separated from the application code in a special class called ApplicationManager.java. This class can be easily modified/recompiled alone, without interfering with the main application or its build. * But will I have to rebuild and redeploy my application everytime I modify my configuration ? Of course no! Because the file ApplicationManager.java is independent from the rest of your application, you can and should recompile it independent from the build of your application, in other words, the file ApplicationManager.class can and should reside outside your application jar. * But will I have to waste time compiling my configuration file all the time ? No! Because the time you will waste recompiling is too little (less than a second) if you compare to the time you will save for not having to debug the mistakes the compiler will catch for you. Compilation is a good thing and the life of the XML frameworks out there would be a little easier if you could compile and validate their XML files before deploying them. Not to say that modern IDEs like Eclipse can compile and auto-complete your code as you type. How about XML ? * But will I have to restart my application context everytime I modify my configuration ? Don't you already do it anyway with XML frameworks ? But the answer is No! Starting on version 1.2, Mentawai will support hot redeploy of the ApplicationManager.class file, in other words, the controller will detect and reload this file once it is modified in disk. * I still do not want to recompile my configuration! That's fine. You can use a scripting language like Ruby, Phyton, Groovy, BeanShell, etc. to write your configuration. Mentawai already comes with built-in support for BeanShell. Support for JRuby, Jython and Groovy will come soon.
  79. Not only do these frameworks do the job, but developers who use them seem fairly happy.


    I don't think so. Open your eyes and see that a huge amount of people are migrating to Ruby and RoR because they are tired of Struts, WebWork and SpringMVC. They say they are easy and do the job, but in practice the story is different.

    Therefore, I think that your claim is wrong, but I'm curious: if it's not XML, how would you suggest we describe data that can be changed without requiring compilation?


    You definitely need to take a look on Mentawai, specially the FAQ session in the cover page (http://www.mentaframework.org). I will save you some time and post it here:


    * Isn't it wrong to place configuration into code?

    Yes! Mentawai does not put configuration into code at all. Although Mentawai configuration is done in Java, it is totally separated from the application code in a special class called ApplicationManager.java. This class can be easily modified/recompiled alone, without interfering with the main application or its build.

    * But will I have to rebuild and redeploy my application everytime I modify my configuration ?

    Of course no! Because the file ApplicationManager.java is independent from the rest of your application, you can and should recompile it independent from the build of your application, in other words, the file ApplicationManager.class can and should reside outside your application jar.

    * But will I have to waste time compiling my configuration file all the time ?

    No! Because the time you will waste recompiling is too little (less than a second) if you compare to the time you will save for not having to debug the mistakes the compiler will catch for you. Compilation is a good thing and the life of the XML frameworks out there would be a little easier if you could compile and validate their XML files before deploying them. Not to say that modern IDEs like Eclipse can compile and auto-complete your code as you type. How about XML ?

    * But will I have to restart my application context everytime I modify my configuration ?

    Don't you already do it anyway with XML frameworks ? But the answer is No! Starting on version 1.2, Mentawai will support hot redeploy of the ApplicationManager.class file, in other words, the controller will detect and reload this file once it is modified in disk.

    * I still do not want to recompile my configuration!

    That's fine. You can use a scripting language like Ruby, Phyton, Groovy, BeanShell, etc. to write your configuration. Mentawai already comes with built-in support for BeanShell. Support for JRuby, Jython and Groovy will come soon.

    I second that, Metawai looks pretty nice, I like the code based configuration part, which you can easily initialize in any invironment and I take it reconfigure at runtime. I recently had a need for DI in a framework I'm working on and chose to use my own simple implementation, since rudimentary DI is easy to implement. I mostly hesitant to use Spring, due to the XML configuratio piece. Spring is great for building applications, due to it's container lifecycle/DI, integration with various frameworks, etc..., and I've used it alot, but for framework or library development, XML just bloats it. PicoContainer is great, as it's a lightweight DI implementation through code configuration. I still didn't use it for various reasons. Ilya
  80. Not only do these frameworks do the job, but developers who use them seem fairly happy.
    I don't think so. Open your eyes and see that a huge amount of people are migrating to Ruby and RoR because they are tired of Struts, WebWork and SpringMVC.
    I don't see how this contradicts my statement. Sure, you always have people migrating away from Java. Today it's Ruby, tomorrow it might be C# or the new language of the month. This doesn't change the fact that hundreds of thousands of Java developers are using Spring, WebWork and Hibernate and are, as I was claiming, very happy with these, despite their strong foundation on XML. I was just asking you how you could reconcile this simple fact with your claim that XML should never be used for configuration, but you don't seem interested in answering... -- Cedric
  81. Actually, it is nicer when IoC wiring, OR mapping etc. are done in Java. It can and is being done. Just that frameworks like Spring and Hibernate set the stage early and folks have been following ever since. With Annotations and AOP -- XML is becoming less useful in Configuration matters - and I like it.
  82. For IoC you can have something as simple as: filter(new IoCFilter()); ioc("userDAO", MySqlUserDAO.class); Than if you want to add DI to inject a connection inside your DAO, you can do something as simple as: filter(new IoCFilter()); filter(new DIFilter()); ioc("userDAO", MySqlUserDAO.class).di("conn", Connection.class); Or if you want everything to receive a connection you can do: filter(new DIFilter("conn", Connection.class)); Programmaticaly configuration is more powerful, more natural, more organized, can be divided into modules, packages, classes, support loops, ifs, function, can be accomplished through DSL, etc. It even has javadocs and it can even be compiled to catch errors. PLUS: Eclipse will do this autommaticaly for you while you type. Welcome to Mentawai (http://www.mentaframework.org)
  83. Programmaticaly configuration is more powerful, more natural, more organized, can be divided into modules, packages, classes
    You keep making these claims without showing any proof. Basically, your approach is to turn a text configuration into binary (Java bytecodes) that can only be read through a special tool (e.g. javap) and modified through another special tool (javac). Maybe you don't mind recompiling every time you change a setting, but trust me, this issue alone is absolutely unacceptable to a lot of projects. -- Cedric

  84. Programmaticaly configuration is more powerful, more natural, more organized, can be divided into modules, packages, classes

    You keep making these claims without showing any proof.

    Basically, your approach is to turn a text configuration into binary (Java bytecodes) that can only be read through a special tool (e.g. javap) and modified through another special tool (javac). Maybe you don't mind recompiling every time you change a setting, but trust me, this issue alone is absolutely unacceptable to a lot of projects.

    --
    Cedric
    What is configuration? IMHO, configuration is information the application needs to run that changes depending on deployment environments. So in most cases something like a database connection string would be configuration. But beyond things like that, whether something needs to be changeable from deployment to deployment is really a function of requirements.

  85. Programmaticaly configuration is more powerful, more natural, more organized, can be divided into modules, packages, classes

    You keep making these claims without showing any proof.

    Basically, your approach is to turn a text configuration into binary (Java bytecodes) that can only be read through a special tool (e.g. javap) and modified through another special tool (javac). Maybe you don't mind recompiling every time you change a setting, but trust me, this issue alone is absolutely unacceptable to a lot of projects.

    --
    Cedric
    Compiling a SINGLE configuration file in Java, in other words a single class file will take a couple of milliseconds. If you are not convinced that this is nothing PLUS if you are not convinced how Eclipse can help you configure your application by compiling as you type THEN you can use a DSL that does not need to be compiled at all. Mentawai already supports Groovy and BeanShell. JRuby is coming out of the oven...
  86. Compiling a SINGLE configuration file in Java, in other words a single class file will take a couple of milliseconds.
    You forget all the files that depend on that configuration file, which is, by definition, quite a few. Regardless, even if it were a few milliseconds to compile just that one file, a build comprises much more than just compiling Java code (testing, packaging, and who knows what else), so in effect, modifying a Java file is orders of magnitude more disruptive than changing an XML file. If you've never worked on projects with more than 50,000 lines of code and more than 20 developers, I can understand that none of this resonates with you, though... -- Cedric
  87. Compiling a SINGLE configuration file in Java, in other words a single class file will take a couple of milliseconds.

    You forget all the files that depend on that configuration file, which is, by definition, quite a few.

    Regardless, even if it were a few milliseconds to compile just that one file, a build comprises much more than just compiling Java code (testing, packaging, and who knows what else), so in effect, modifying a Java file is orders of magnitude more disruptive than changing an XML file.

    If you've never worked on projects with more than 50,000 lines of code and more than 20 developers, I can understand that none of this resonates with you, though...

    --
    Cedric
    Be careful not to say something that does not make sense at all. Have you ever heard about reflection ??? Have you ever heard about loading a class by name "com.blah.Foo" ??? YOU DO NOT HAVE TO REBUILD ANYTHING. This is just in your mind. You have only to compile A SINGLE file, your configuration. The rest of your application is someplace else in a jar. For my projects I have a ant config, which will just compile my configuration and ftp to the server. Then mentawai will auto-detect that the ApplicationManager.class has changed and reload everything on the fly. You don't even have to restart the context. PLUS, like I said, you can use BeanShell or Groovy, if you are afraid of compilation. You are too addicted to XML. If you think that making a type in a XML file, getting the syntax wrong, ftping to the server, restarting the context and getting a huge non-sense exception is fun, they you are responsible for the RoR hype.
  88. Be careful not to say something that does not make sense at all.
    The irony of this remark amuses me greatly...
    Have you ever heard about reflection ???
    Oh, this gets better... So you are saying that your framework uses Java for configuration purposes but it foregoes the only potentially positive side of Java, which is type safety? Let me make sure I got this right: if I define a symbol public static final String JAR_FILE = "a.jar", you use reflection to load the class and locate it, so that if I decide to change its name, I can't use refactoring and unless I rename it myself everywhere in my code, my application will just bomb at runtime? Do you even realize the consequences of what you're doing? -- Cedric
  89. Be careful not to say something that does not make sense at all.

    The irony of this remark amuses me greatly...


    Have you ever heard about reflection ???

    Oh, this gets better...

    So you are saying that your framework uses Java for configuration purposes but it foregoes the only potentially positive side of Java, which is type safety?

    Let me make sure I got this right: if I define a symbol public static final String JAR_FILE = "a.jar", you use reflection to load the class and locate it, so that if I decide to change its name, I can't use refactoring and unless I rename it myself everywhere in my code, my application will just bomb at runtime?

    Do you even realize the consequences of what you're doing?

    --
    Cedric
    Dude, I respect you very much, so I will end this discussion. I suggest you take a look in a Mentawai configuration file here (http://www.mentaframework.org/mybooks.jsp), read what Martin Fowler once said about configuration (http://forum.mentaframework.org/posts/list/160.page) and what other people are saying about Mentawai here (http://forum.mentaframework.org/posts/list/143.page). If you are happy with XML configuration, if your project are in time and everybody is happy there is no reason to consider switching for anything else.
  90. I know that this discussion between Cedric and Sergio is over, but I felt the need to add a comment here. Fowler does not say one should not use config files, he is just worried that they might make an application more difficult to maintain.
    "The important issue in all of this is to ensure that the configuration of services is separated from their use... Once you are using plugins then it's essential that the assembly of the plugins is done separately from the rest of the application so that you can substitute different configurations easily for different deployments. How you achieve this is secondary. This configuration mechanism can either configure a service locator, or use injection to configure objects directly."
    Cedric sees the value in using multi-external configs because of the types of problems he is solving at Google. A person like myself who works in a 9 man-single-db-vendor shop may not and therefore would favor the programmatic approach to configuration. In the end though, it is all about the problem are we trying to solve. There is no such thing as a silver bullet because there are no such things as werewolves. IMHO we should stop acting like werewolves exists and start finding the best way to trap the animal thats been killing my chickens all this time! On an unrelated note, I also love this site because there is so much more action going on here than in the .Net group!
  91. Compiling a SINGLE configuration file in Java, in other words a single class file will take a couple of milliseconds.

    You forget all the files that depend on that configuration file, which is, by definition, quite a few.

    Regardless, even if it were a few milliseconds to compile just that one file, a build comprises much more than just compiling Java code (testing, packaging, and who knows what else), so in effect, modifying a Java file is orders of magnitude more disruptive than changing an XML file.

    If you've never worked on projects with more than 50,000 lines of code and more than 20 developers, I can understand that none of this resonates with you, though...

    --
    Cedric
    Besides the fact thay maybe I don't want to compile the production system for a minor config change.
  92. Besides the fact thay maybe I don't want to compile the production system for a minor config change.
    Just because or that depends on trasnsparency and convenience of compillation? Would you still oppose configuration compillation if it was like JSP compillation?
  93. Compiling a SINGLE configuration file in Java, in other words a single class file will take a couple of milliseconds.

    You forget all the files that depend on that configuration file, which is, by definition, quite a few.

    Regardless, even if it were a few milliseconds to compile just that one file, a build comprises much more than just compiling Java code (testing, packaging, and who knows what else), so in effect, modifying a Java file is orders of magnitude more disruptive than changing an XML file.

    If you've never worked on projects with more than 50,000 lines of code and more than 20 developers, I can understand that none of this resonates with you, though...

    --
    Cedric


    Besides the fact thay maybe I don't want to compile the production system for a minor config change.
    Which english is worse? Mine or yours ???? Dude: I wrote in capital and I will say again: THERE IS NO NEED TO RECOMPILE YOUR WHOLE APPLICATION !!! YOU JUST COMPILE A SINGLE FILE !!! THIS FILE IS APPART FROM YOUR APPLICATION !!! When you change your JSP do you need to recompile the whole application ????????????????????? My friend, i get 10 arguments like that per day, that's why there is a huge FAQ on the first page of the project. I have posted the FAQ here, but people don't read. Some people read but don't understand or believe. It is crazy. Again: you have two options: 1) Use Java and compile A SINGLE CONFIGURATION file. 2) Use BeanShell, Grooxy, JRuby and use your configuration pretty much like a JSP. You change it in the production server (if you want to) and it will be reloaded on the fly. PS: Mentawai also supports on-the-fly reload of ApplicationManager.class, so if you copy a recompiled version of ApplicationManager.java to the webserver it will reload without the need to restart the context. Well, if you still think you need to rebuild your whole application, then you are right!
  94. Sorry, I had a bad day today. Just got home after 15 hours of work.
  95. When it comes to IoC - its just not configuration - you are wiring Java objects - and using XML to do it - that just seems wrong. I think the same applies to Test and O-R framworks where Meta information about "Java Classes" are being described outside of Java using XML. I see configuration as stuff that developers will not change, but Business, Operations or your Users want to change. These are usually small enough to encapsulate into regular Java Properties files or into the App-Servers. In the cases where this is not true - an XML configuration file may be valid.
  96. Yes, use Java packages and separate Jars with SPI or similar to separate out functionality. Design interfaces to abstract out your needs and just drop in another Jar. I just don't believe IoC Wirings or meta data about Java classes are "Configuration". Only developers understand and modify them - not your users, not your biz, not ur operations.
  97. bingo[ Go to top ]

    I just don't believe IoC Wirings or meta data about Java classes are "Configuration". Only developers understand and modify them - not your users, not your biz, not ur operations.
    bingo
  98. XML should be platform independent data, and nothing more than that. It is huge, it is akward, and is annoying, but that what it is. DATA.

    I think XML should not be used for any kind of configuration at all.

    I think XML should not be used to model business logic.
    IMHO, your opinion here is as extreme as Allens. The use of "external" text files to configure applications is common practice for ages. Before XML we had "Property" files and before that we had other formats. The imporant reason to do that is that anyone can change the configuration with a simple text-editor. No need to tell an administrator to edit and compile a java file. XML in this context is just a different format. Where I agree is that programming-logic/flow should not be unnecessarily "externalized". When you move your logic into an XML file, you lose compile-time checks, use of IDE tools and debug ability. These negative affects far outweigh any perceived gain in moving logic to XML files. But what I criticise here is the "process" of moving logic out of the java-world, not the format how it is stored. Therefor Allens proposal to write your own scripting-langauge/compiler doesn't make it better.
  99. Synergy[ Go to top ]

    Most people totally miss the point of XML. Allen Holub is just missing it by a greater margin. The point of XML is synergy between all the different kinds of things that can be represented as XML data. XML is a great step forward towards building-block programming. For example, I can send an XML message over soap, get an XML response back, and use XSLT to transform it into SVG to make a pretty graph of the results. The alternative is using all kinds of individual protocols, each with their own grammer, and assembling the results. Each one might indiviudally be simpler than the equivalent XML version, but putting them all together is a pain in the ass. PS : Ant is awesome and is not a scripting language anyway. I lost all respect for his argument when he used it as an example.
  100. My boss will like that...[ Go to top ]

    I can imagine my bosses face when I will tell them : "Instead of using XML, XSD and use standard librairies to define, parse and write the files we exchange with our clients external systems and develop it in 2 weeks, we will write our own in-house compiler/parser and force them to learn it and write special code to use it and it will take us 6 months." Or "We could have built this application using Spring and its integrated features and saved a lot of time, but I decided that XML sucked so I decided to write our own complete compiler so we busted our budget" hehehehe so funny
  101. Re: My boss will like that...[ Go to top ]

    Of the many comments on this thread, this is my favorite. I really think we get caught up to much in theoretical arguments. Most of us have bosses, and they want results....
  102. Re: Allen Holub: Just Say No to XML[ Go to top ]

    With all due respect of Mr. Holub, I would say he is bit too late to say things like that. One thing is true that XML is over hyped and we discuss it 1000 times on the forums like this; but hey you can't win over the marketing machine of MS and IBM:-) Can you?
  103. Hmm[ Go to top ]

    Personally I believe that CSV is the worst programming language ever...
  104. use the right tool[ Go to top ]

    We just don't need to be runing behind every new fashion (tool or technology). Just use the right tool for the right porpouse as you wouldn't use the fork to drink the soap. I consider XML good for B2B, web services and some hierarchical configuration. I don't consider XML so good to program (I would prefer a comiler instead) or to store a plain-ini file (I prefer a .INI file instead). From my point of view: -Good usage: web.xml and server.xml in tomcat configuration (is basically hierarchical configuracion) -Bad usage: hibernate.cfg.xml, because it could be easier as an .ini file (property=value) or as a hierarchical xml, for example: org.hibernate.transaction.JDBCTransactionFactory is not a good xml way because it shows the hierarchical way "hibernate/transaction/factory_class" that can be expressed better in xml. Nowadays we are all running behind AJAX and it seems that a non-ajax software is not a software at all. Just use it in the correct places (for example, to refresh combos that depend each other). Marcos.
  105. Andrew Appel's book[ Go to top ]

    Modern Compile Implementation in Java by Andrew Appel, is good.There's another book called Building Parsers With Java that's also decent, but not as good. Of course, just reading the JavaCC documentation is probably an even better way to learn. Most of the compilers we need to write don't actually go down to register allocation. Like writing a JDOQL compiler -- I just used JavaCC to parse the JDOQL and build an AST, then operate on the AST to transform to SQL. Anyhow, I think the basic problem the author of the article was getting at, is that many problems at first seem like a "data problem". Like building an OR mapping format in XML. What happens is that, the deeper you get into it, you really find out that you need all these little hooks, and id's to correlate one element to another, and escape hatches to invoke classes. Things can get out of hand quickly. Now, I don't know that another mini-language is the solution. For this particular case (ORM), I found that simply creating an interface in Java, and letting the developer implement the interface, worked fine, I've blogged a little bit about that issue with ORM, here http://notskateboarding.blogspot.com/ under the Friday, August 11, 2006 entry. -geoff
  106. DSLs without rolling your own[ Go to top ]

    I agree with a lot of Holub's article: XML is not the appropriate language for a lot of its applications (Ant scripts, Hibernate, ... , but it gets used because you get the language processing for free. And I think any real developer ought to be able to crank out a basic lexer, recursive-descent parser, and byte-code (or parse tree) interpreter. Still, language design is an art, and not everyone's got the chops. Let me suggest a middle way between YAXMLWTF and designing your own language and writing a compiler for it: using an embedded scripting language. You can embed engines for Python, Ruby, JavaScript (respectively Jython, JRuby, and Rhino in the Java word) and communicate back and forth between the two worlds. (And there are other options besides these three.) You get open source working code, documents(!), examples of how to glue the pieces together. In language terms, you get straightforward ways of writing dictionaries and lists, the basic data structure bulding blocks you need for most declarative data. You get variables. You get procedures and objects if you need them. You effectively get macros -- you can write functions that return data structures (or other functions). With Python I know you get nice function syntax for positional and/or named arguments and default values of said functions. By populating the name space of your scripts with the appropriate constants, functions, objects, classes, whatever, you can get pretty far with making your very own domain-specific language, that's apt to be more appropriate than XML.
  107. Scripting would be great IF we had a robust way to communicate which objects are exposed to the script and get code completion and navigation to work when we write the script. for example, if we expose foo, and bar, variables to the script we also have to provide documentation to describe those objects and if some methods return complex object Zoo, we need to document it too. In case of XML there can be schema or DTD that will be recognized by any decent XML editor and that will automagically convey to the user that only foo, and bar tags are allowed and that they have a,b,and c attributes, and that there might be child tag 'zoo' with its own attributes and nodes. I think that developers will switch to DSLangs or scripts on the heartbeat when tools like MPS will become robust enough and widespread.
  108. abusus non tollit usum[ Go to top ]

    abusus non tollit usum Translation: misuse does not nullify proper use Steve Polyak Pearson Educational Measurement
  109. The title should read...[ Go to top ]

    "Just Say No To LISP" instead ;^)
  110. In defense of Hibernate...[ Go to top ]

    First my qualifications: I once took a class from Allen Holub...and after a few sessions concluded that he was pretty much out to lunch, probably having spent too much time in academia and having never actually created and maintained any real software himself. I went on to found a software company (www.navis.com) now with annual revenues of $50M where I continue to code everyday. I feel that XML is perfectly adequate for anything declarative, and this includes the Hibernate O-R mapping file. Unfortunately, some people got carried away and created programming/scripting languages in XML, including ant and XSLT. The ant author himself has admitted this was a mistake (noted above). I don't know who is responsible for XSLT, but everytime I sit down to use it I am frustrated by how long it takes to (re)wrap my head around it. Finally, as a boss, I'd now like to recommend that the rest of you now get back to work.
  111. As a compromise between what's easy to process by machines and easy to author by humans, XML clearly strikes more of a balance in favor of the machine and should be confined to under the hood representations, to benefit of XML's true desirable properties while hiding its ugly face. However, the widespread use of XML beyond mere internal data representation is perfectly understandable: XML parsers are generic, minimalistic and readily available in just about any flavor. The XML itself is human inspectable without requiring involved toolchains, allows for flexibile interpretation schemes in different contexts. Compare this against the staple compiler construction tools the author of this article would resort to (barring handcrafting one). I don't subscribe to the view that leaving a DSL in XML state is necessarily due to selfishness or lack of compiler construction knowledge. It is more a matter of convenience, and state of affairs in the compiler construction toolchain department. The truth is that most of the toolchains for compiler construction are severely antiquated, with even more undersirable syntaxes. The human-intelligible language for expressing language grammars is BNF / EBNF, yet the stock parser generators like yacc, pccts, coco/r, fail to process EBNF in a pure form, and nearly always intermingle semantic actions in the grammar using the syntax of the programming language of the month. One notable exception, http://www.sablecc.org, goes all the way, accepts EBNF as a linguist would express it with little compromise in favor of the machine, and generates a parser in a target language of choice that produces ASTs + AST visitor classes that can then be used to actually process the DSL. However, even armed with a modern compiler writing productivity tool like sablecc, writing a domain specific language processor that meets modern expectations is going to be more labor intensive than putting a generic XML parser to work. In the context of DSL development, XML does have potential merits: it can be used to introduce a separation of concerns in parser/compiler construction. For prototyping, XML can be used as an interim specification language, allowing for the focus to be immediately on the prime motivation for introducing the new language in the first place. Once the DSLs concept has been proven to be worth the while in practice, the altruistic developer can then proceed with the development of human friendly DSL processor, producing the interim XML representation (as opposed to the ASTs typically used for this purpose). That then, is where the other desirable characteristics of XML kick in: different tools can look at the same XML with a different perspective, and when properly conceived, with tolerance to change. Taking this a step furter: I expect that in the end, we'll all realize we had it right the first time around (late 50's) with LISP, where a sober syntax is used to express both instruction and data with an option to extend the syntax for more declarative, domain specific purposes. Now most of us are working with 3 or more aberrations of an originally clean syntax: C without the sharps, the plusses, the generics and the coffee, to process a bastardized version of LISP for data representations. P.S. While I agree that using XML to write build scripts is abusive of humans (too much typing), 'make', a tool with a dedicated syntax is barely better. Personally, I think a build script should be generated simply on the programmer's indication where the sources are. Sureley, after laying out the sources neatly in hierarchical namespaces, the machine should be able to figure out what the entry points and dependencies are on its own devices.