5 ms·

Please give better examples: > Anyway, after trying to configure stuff like Kafka, Zookeeper and Maven and setting up a SOAP API, I saw that the problem with J

by agentgt 10y ago

Please give better examples: > Anyway, after trying to configure stuff like Kafka, Zookeeper and Maven and setting up a SOAP API, I saw that the problem with Java isn't the language * Kafka: is written in Scala. It doesn't use XML. * Zookeeper: it was the first of its kind. It doesn't use XML. * Maven: same complexity as SBT, Gradle, etc... but it is declarative and again pretty much first of its kind (dependency management + build). * SOAP: this is not Java's fault (if anything Microsoft was the big pusher) * XML: jesus will people stop the XML is complex and hard thing. YAML is so much more complicated and harder to parse. I know it is easy to read on the eyes but its harder to parse and has more edge cases. XML is still one of the few languages you can parse and manipulate and preserve comments and whitespace. The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML (pedantically HTML5 is even more complicated since it allows SGML and XML style). But for some reason when people have to write a build or config file that they are rarely going to have to edit their fingers, eyes, and brains revolt at the complexity. Scala also has some massively complicated libraries like Akka. Ruby has Rails. When languages/libraries get mature they get complicated and the languages warts show more and more. I expect we will see the same thing even with modern languages like Go and Rust.

rco8786 10y ago
Agreed up until the XML bit. It's not "XML vs YAML", it's "Why do you need all this static markup at all?".
- agentgt 10y ago
  If this is going along the lines of S-Expressions I say touche but it is what it is. You need markup instead of code sometimes because you want declarative configuration. You want to sandbox a developer/user. Yeah you can write declarative code in Scala (and many languages using Monads, macros or some sort of non imperative abstraction) using an embedded DSL... but it is embedded and hard to enforce someone from sticking a System.exit(1) somewhere. Again If you are in the Lisp camp I submit there are better options.
gnaritas 10y ago
> The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML As if developers like HTML any better. I agree with you about XML being useful because it's easy to parse and the XML hate is overhyped, but that's not what he's saying, he's complaining about configuration hell that seems intrinsic to the Java ecosystem as compared to something like Rails which relies far more on convention than configuration. That's a cultural problem, not a language problem.
- agentgt 10y ago
  There are pros and cons to both ways (aka convention over configuration). That is hiding configuration complexity often get fixed with even more internal complexity except now it is hidden. With hiding configuration your ramp up time decreases but your overall understanding of how the library/framework may decrease. To offer the advantages of both requires even more complexity. Which is actually what happened with Spring Boot. It is the Ruby on Rails of Java now and it is far more complex internally than the olden days of Spring 2.0 explicit XML. At times I miss the old school Spring XML way. There used to be only like 4 tags (bean, property and include).
cle 10y ago
The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML, because doing non-trivial dynamic things in Java itself can be a huge pain. And so over time, enterprise Java apps became giant balls of XML+Java that would break at runtime if you missed an XML parameter or had a stray character somewhere. At that point, what benefit are you getting from Java's static typing? You lose much of the benefits of Java, and suffer twice as much from its drawbacks. This is slightly better with the push away from XML and toward annotations, but it's not much better. Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO.
- agentgt 10y ago
  > The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML You are going to have to show some examples. > because doing non-trivial dynamic things in Java itself can be a huge pain Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go. You have to remember one of the reasons why there was a shit load of declarative configuration in old Java for enterprise is because software was on premise software. Customers would have different databases, hardware, etc. And there was no way you could say to those customers: "hey how about you go recompile this and that" or "use this syntactically weird DSL". Really the only better enterprise option back in those days was Lisp we all know how that played out. > Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO. I agree/disagree. It depends on context. Annotations are declarative and thus IMO easier to not screw up and even easier to understand in many cases. Particularly for serialization and code generation. Most languages now have some sort of annotations and this is for good reason. But yeah too much (annotations) is a bad thing. Java now has annotation overload (spring boot).... probably because people bitched about XML :) ... pretty soon will have convention overload as well (Spring Boot is heading down that path as well like Rails). You can always take the explicit programmatic option... you know like wiring up your own beans and writing manual SQL but people want "magic". There is probably an even ground somewhere.
legulere 10y ago
> YAML is so much more complicated and harder to parse. YAML has more complexity in syntax, but a data model that fits to data structures in programming languages (records/maps, arrays/lists, integers, floats, boolean, bytes, strings). As long as you do not implement a YAML parser yourself (why would you do that?) you should have easy times with YAML. XML on the other hand is relatively easy to parse, but has a complex data model that maps well just to a DOM. For anything but markup text, you do not have a direct mapping to/from XML. > Developers write hundreds of lines of XML all the time... its called HTML There it makes sense, because it is marked up text you are writing and it is the right tool for the job.
- agentgt 10y ago
  > YAML has more complexity in syntax, but a data model that fits to data structures in programming languages (records/maps, arrays/lists, integers, floats, boolean, bytes, strings). As long as you do not implement a YAML parser yourself (why would you do that?) you should have easy times with YAML. I mostly agree but YAML sounds like a serialization format and not configuration format to me. I think a large amount programmers don't realize nor respect the history. Early Java proliferation was during the late 90s and early 2000 on-premise enterprise software. Customers required extreme customization but not all of them wanted to actually crack open and edit files. The customers wanted to use tools and XML works great for bidirectionally editing not to mention there were shit loads of XML editing tools at the time (XML Spy). > XML on the other hand is relatively easy to parse, but has a complex data model that maps well just to a DOM. For anything but markup text, you do not have a direct mapping to/from XML. One of the reasons Java originally pushed XML is the support for it so good (tooling and editors). Java actually has great support for mapping XML to objects (JAXB).
jgalt212 10y ago
> YAML is so much more complicated and harder to parse. That's only true if you stray far from the core. If you stay to the language agnostic parts, it's clean and readable.
coldtea 10y ago
>Kafka: is written in Scala. It doesn't use XML. Zookeeper: it was the first of its kind. It doesn't use XML. Which is beside the point, since the parent complained about the needless complexity and layers, not just about use of XML. >Maven: same complexity as SBT, Gradle, etc... Which is to say: more than the task requires. >XML: jesus will people stop the XML is complex and hard thing. YAML is so much more complicated and harder to parse. I know it is easy to read on the eyes but its harder to parse and has more edge cases. It's not about whether it's easy to parse or not, it's about being easy to write and read when we're talking about a configuration format. And XML in all its glory is hardly easy to parse, except if you mean by using a ready-made existing parser. In which case, everything is easy to parse (and most things, easier than XML to extract values from). >XML is still one of the few languages you can parse and manipulate and preserve comments and whitespace. Why would I care for "preserving comments and whitespace" in a configuration format? Except if I was doing something needlessly complex, like generating configuration on the fly on top of user edited configuration. Which, the doing needlessly complex stuff, is what the parent complained about. >The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML (pedantically HTML5 is even more complicated since it allows SGML and XML style). Unless those developers are web developers, and especially front-end web developers, no, they don't. And even if they did, it's one thing to write HTML in its intended domain, and totally another to have to write it (or specifically XML) for configuration. In all, these sound more like "it's always been done that way" and Stockholm Syndrome than actual convincing arguments.
- agentgt 10y ago
  I'm curious... what do you propose instead of XML for configuration. You know that is standard and everybody knows it. Remember Java was/is very good at parsing XML. > In all, these sound more like "it's always been done that way" and Stockholm Syndrome than actual convincing arguments. And yeah it is Stockholm Syndrome because shit hasn't gotten that much better. Editing massive YAML or JSON files isn't really any easier IMO. You can't even put a comment in a JSON file and unless you are using Emacs I think even S-Expressions are not easier. > It's not about whether it's easy to parse or not, it's about being easy to write and read when we're talking about a configuration format. And XML in all its glory is hardly easy to parse, except if you mean by using a ready-made existing parser. Except XML is extremely standardized and well established and yeah there are parsers in almost every language. JSON has changed its standard a ton of times. It actually is really hard to parse correctly [1]. > (and most things, easier than XML to extract values from) XML has XPath and XQuery. Both very well defined and have backing standards. ie not a random github project just supporting one language which is the case for JSON path. IMO XML is one of the easiest formats to extract data from. Even CSV is scary to parse correctly. >Why would I care for "preserving comments and whitespace" in a configuration format? Except if I was doing something needlessly complex, like generating configuration on the fly on top of user edited configuration. Which, the doing needlessly complex stuff, is what the parent complained about. It isn't needlessly complex if there are requirements for such. Maven was designed to be declarative and the hope was it could be imported by IDEs which it successfully achieved. You know one of the reasons why Rails and various other easy to use frameworks came about is you don't need as much complexity if it is a hosted model. You don't need massive configuration if you are hosting and not delivering on premise software. So circa mid 2000 was the Rails crowd trashing the enterprise Java and probably deservedly sow. However things are shifting back towards needing complex requirements because people want their cloud stuff to have elasticity, reliability, failover, etc (aka zookeeper) and that shit requires complexity. People complain about the complexity of Java but I honestly think modern frontend web development is so awful today that I would take even old shitty j2ee over it almost any day (well maybe not that far but close to it). [1]: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php

by agentgt 10y ago

rco8786 10y ago

Agreed up until the XML bit. It's not "XML vs YAML", it's "Why do you need all this static markup at all?".

agentgt 10y ago
If this is going along the lines of S-Expressions I say touche but it is what it is. You need markup instead of code sometimes because you want declarative configuration. You want to sandbox a developer/user. Yeah you can write declarative code in Scala (and many languages using Monads, macros or some sort of non imperative abstraction) using an embedded DSL... but it is embedded and hard to enforce someone from sticking a System.exit(1) somewhere. Again If you are in the Lisp camp I submit there are better options.

gnaritas 10y ago

> The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML As if developers like HTML any better. I agree with you about XML being useful because it's easy to parse and the XML hate is overhyped, but that's not what he's saying, he's complaining about configuration hell that seems intrinsic to the Java ecosystem as compared to something like Rails which relies far more on convention than configuration. That's a cultural problem, not a language problem.

agentgt 10y ago
There are pros and cons to both ways (aka convention over configuration). That is hiding configuration complexity often get fixed with even more internal complexity except now it is hidden. With hiding configuration your ramp up time decreases but your overall understanding of how the library/framework may decrease. To offer the advantages of both requires even more complexity. Which is actually what happened with Spring Boot. It is the Ruby on Rails of Java now and it is far more complex internally than the olden days of Spring 2.0 explicit XML. At times I miss the old school Spring XML way. There used to be only like 4 tags (bean, property and include).

cle 10y ago

The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML, because doing non-trivial dynamic things in Java itself can be a huge pain. And so over time, enterprise Java apps became giant balls of XML+Java that would break at runtime if you missed an XML parameter or had a stray character somewhere. At that point, what benefit are you getting from Java's static typing? You lose much of the benefits of Java, and suffer twice as much from its drawbacks. This is slightly better with the push away from XML and toward annotations, but it's not much better. Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO.

agentgt 10y ago
> The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML You are going to have to show some examples. > because doing non-trivial dynamic things in Java itself can be a huge pain Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go. You have to remember one of the reasons why there was a shit load of declarative configuration in old Java for enterprise is because software was on premise software. Customers would have different databases, hardware, etc. And there was no way you could say to those customers: "hey how about you go recompile this and that" or "use this syntactically weird DSL". Really the only better enterprise option back in those days was Lisp we all know how that played out. > Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO. I agree/disagree. It depends on context. Annotations are declarative and thus IMO easier to not screw up and even easier to understand in many cases. Particularly for serialization and code generation. Most languages now have some sort of annotations and this is for good reason. But yeah too much (annotations) is a bad thing. Java now has annotation overload (spring boot).... probably because people bitched about XML :) ... pretty soon will have convention overload as well (Spring Boot is heading down that path as well like Rails). You can always take the explicit programmatic option... you know like wiring up your own beans and writing manual SQL but people want "magic". There is probably an even ground somewhere.

legulere 10y ago

> YAML is so much more complicated and harder to parse. YAML has more complexity in syntax, but a data model that fits to data structures in programming languages (records/maps, arrays/lists, integers, floats, boolean, bytes, strings). As long as you do not implement a YAML parser yourself (why would you do that?) you should have easy times with YAML. XML on the other hand is relatively easy to parse, but has a complex data model that maps well just to a DOM. For anything but markup text, you do not have a direct mapping to/from XML. > Developers write hundreds of lines of XML all the time... its called HTML There it makes sense, because it is marked up text you are writing and it is the right tool for the job.

agentgt 10y ago
> YAML has more complexity in syntax, but a data model that fits to data structures in programming languages (records/maps, arrays/lists, integers, floats, boolean, bytes, strings). As long as you do not implement a YAML parser yourself (why would you do that?) you should have easy times with YAML. I mostly agree but YAML sounds like a serialization format and not configuration format to me. I think a large amount programmers don't realize nor respect the history. Early Java proliferation was during the late 90s and early 2000 on-premise enterprise software. Customers required extreme customization but not all of them wanted to actually crack open and edit files. The customers wanted to use tools and XML works great for bidirectionally editing not to mention there were shit loads of XML editing tools at the time (XML Spy). > XML on the other hand is relatively easy to parse, but has a complex data model that maps well just to a DOM. For anything but markup text, you do not have a direct mapping to/from XML. One of the reasons Java originally pushed XML is the support for it so good (tooling and editors). Java actually has great support for mapping XML to objects (JAXB).

jgalt212 10y ago

> YAML is so much more complicated and harder to parse. That's only true if you stray far from the core. If you stay to the language agnostic parts, it's clean and readable.

coldtea 10y ago

>Kafka: is written in Scala. It doesn't use XML. Zookeeper: it was the first of its kind. It doesn't use XML. Which is beside the point, since the parent complained about the needless complexity and layers, not just about use of XML. >Maven: same complexity as SBT, Gradle, etc... Which is to say: more than the task requires. >XML: jesus will people stop the XML is complex and hard thing. YAML is so much more complicated and harder to parse. I know it is easy to read on the eyes but its harder to parse and has more edge cases. It's not about whether it's easy to parse or not, it's about being easy to write and read when we're talking about a configuration format. And XML in all its glory is hardly easy to parse, except if you mean by using a ready-made existing parser. In which case, everything is easy to parse (and most things, easier than XML to extract values from). >XML is still one of the few languages you can parse and manipulate and preserve comments and whitespace. Why would I care for "preserving comments and whitespace" in a configuration format? Except if I was doing something needlessly complex, like generating configuration on the fly on top of user edited configuration. Which, the doing needlessly complex stuff, is what the parent complained about. >The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML (pedantically HTML5 is even more complicated since it allows SGML and XML style). Unless those developers are web developers, and especially front-end web developers, no, they don't. And even if they did, it's one thing to write HTML in its intended domain, and totally another to have to write it (or specifically XML) for configuration. In all, these sound more like "it's always been done that way" and Stockholm Syndrome than actual convincing arguments.

agentgt 10y ago
I'm curious... what do you propose instead of XML for configuration. You know that is standard and everybody knows it. Remember Java was/is very good at parsing XML. > In all, these sound more like "it's always been done that way" and Stockholm Syndrome than actual convincing arguments. And yeah it is Stockholm Syndrome because shit hasn't gotten that much better. Editing massive YAML or JSON files isn't really any easier IMO. You can't even put a comment in a JSON file and unless you are using Emacs I think even S-Expressions are not easier. > It's not about whether it's easy to parse or not, it's about being easy to write and read when we're talking about a configuration format. And XML in all its glory is hardly easy to parse, except if you mean by using a ready-made existing parser. Except XML is extremely standardized and well established and yeah there are parsers in almost every language. JSON has changed its standard a ton of times. It actually is really hard to parse correctly [1]. > (and most things, easier than XML to extract values from) XML has XPath and XQuery. Both very well defined and have backing standards. ie not a random github project just supporting one language which is the case for JSON path. IMO XML is one of the easiest formats to extract data from. Even CSV is scary to parse correctly. >Why would I care for "preserving comments and whitespace" in a configuration format? Except if I was doing something needlessly complex, like generating configuration on the fly on top of user edited configuration. Which, the doing needlessly complex stuff, is what the parent complained about. It isn't needlessly complex if there are requirements for such. Maven was designed to be declarative and the hope was it could be imported by IDEs which it successfully achieved. You know one of the reasons why Rails and various other easy to use frameworks came about is you don't need as much complexity if it is a hosted model. You don't need massive configuration if you are hosting and not delivering on premise software. So circa mid 2000 was the Rails crowd trashing the enterprise Java and probably deservedly sow. However things are shifting back towards needing complex requirements because people want their cloud stuff to have elasticity, reliability, failover, etc (aka zookeeper) and that shit requires complexity. People complain about the complexity of Java but I honestly think modern frontend web development is so awful today that I would take even old shitty j2ee over it almost any day (well maybe not that far but close to it). [1]: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php