4 ms·

Totally. On two totally independent occasions I've come into work to have a coworker tell me they implemented an XML Parser the evening before. Um, right. Grea

Totally. On two totally independent occasions I've come into work to have a coworker tell me they implemented an XML Parser the evening before. Um, right. Great. The thing that totally boggles my mind is that I think it really prove-ably fails to deliver on literally every promise/benefit/design-goal that I hear folks claim it embodies.

kamaal 16y ago
I know parsing XML with regular expressions is a sin, but when you need to get some data out a 20 GB XML immediately in the next 10 minutes. It turns out that its better to check out the layout of the XML, use combinations of grep, sed, awk , perl with pipes just to serve the need for the moment. This is better than spending next 5 hours writing a Java program to do it. Its not a permanent solution, but either way that Java program and the shell hack are both going to do the very same. I would rather use the shell and do it, rather than spend the next 5 hours with Java and eclipse.
- haberman 16y ago
  The fact that those are your two options is just a testament to how absurdly unsuitable XML is for this purpose. Your "combinations of grep, sed, awk, perl" will corrupt your data if your file happens to contain any CDATA, entities, unexpected formatting, processing instructions, etc. Don't get me wrong, sometimes a quick hack is worth the risk. But it's certainly no reason to defend XML, which is what put you in the position where a quick hack was your best option.
  - kamaal 16y ago
    I agree with you. Actually I'm not too much in favor of XML either. Somebody high up in the hierarchy attends a few conferences here and there, reads the IBM journal. All along the word 'XML' gets repeated some 1000 times. So the impression he gets is, XML is going to add value to everything it touches. Most developers like me have no say in that at all, we have to just use it. I prefer the hack to get it just done. But agree with you, none of that is a permanent solution.
- pasbesoin 16y ago
  I've similarly seen simple pattern matching used in high transaction volume processing. Using a DOM based, or even a stream based processor is considered too expensive. So, just look for the relevant tag and grab the next bit, while presuming that the context is correct. (This involved a limited number of trusted partners, in a relatively steady-state environment.) OTOH, it eliminated discussions/arguments about what format to use. In a corporate environment, that can be a significant win in and of itself. (Yes, "win" should be in quotes.)

kamaal 16y ago

I know parsing XML with regular expressions is a sin, but when you need to get some data out a 20 GB XML immediately in the next 10 minutes. It turns out that its better to check out the layout of the XML, use combinations of grep, sed, awk , perl with pipes just to serve the need for the moment. This is better than spending next 5 hours writing a Java program to do it. Its not a permanent solution, but either way that Java program and the shell hack are both going to do the very same. I would rather use the shell and do it, rather than spend the next 5 hours with Java and eclipse.

haberman 16y ago
The fact that those are your two options is just a testament to how absurdly unsuitable XML is for this purpose. Your "combinations of grep, sed, awk, perl" will corrupt your data if your file happens to contain any CDATA, entities, unexpected formatting, processing instructions, etc. Don't get me wrong, sometimes a quick hack is worth the risk. But it's certainly no reason to defend XML, which is what put you in the position where a quick hack was your best option.
- kamaal 16y ago
  I agree with you. Actually I'm not too much in favor of XML either. Somebody high up in the hierarchy attends a few conferences here and there, reads the IBM journal. All along the word 'XML' gets repeated some 1000 times. So the impression he gets is, XML is going to add value to everything it touches. Most developers like me have no say in that at all, we have to just use it. I prefer the hack to get it just done. But agree with you, none of that is a permanent solution.
pasbesoin 16y ago
I've similarly seen simple pattern matching used in high transaction volume processing. Using a DOM based, or even a stream based processor is considered too expensive. So, just look for the relevant tag and grab the next bit, while presuming that the context is correct. (This involved a limited number of trusted partners, in a relatively steady-state environment.) OTOH, it eliminated discussions/arguments about what format to use. In a corporate environment, that can be a significant win in and of itself. (Yes, "win" should be in quotes.)