• Onyx (disco)

    Logic via XML? That’s a WTF all by itself, sure. But TRWTF is

    trying to embed an image right next to deeply nested XML... :rolleyes:

  • Nprz (disco)
    Comment held for moderation.
  • dbenzhuser (disco) in reply to Onyx

    TRWTF is an 11.3 MB picture in the article.

  • Nprz (disco) in reply to dbenzhuser

    Thank god for fiber, eh? Reminds me of back when browsers would fail to download images, so you could right-click and do "Show Picture" (or configure the browser to not auto-load the image).

  • chrullrich (disco)

    TRWTF ... is letting Huawei get a(hua)way with that format. (Or whoever masquerades as them ...)

  • RaceProUK (disco)

    Logic via XML? That’s a WTF all by itself, sure.

    Never stopped XSLT…

  • VinDuv (disco)

    Providing arithmetic operators in an XML file is just begging for this sort of code to be written...

  • Gaska (disco)

    If it was C++ templates rather than XML, I'm sure there would be people who would see it as a reasonable thing to do.

  • TheCPUWizard (disco)

    For those saying Logic in XML is WTF....please provide a runtime configurable alternative. No matter the format, you are going to end up with deeply nested structures.

  • icebrain (disco) in reply to TheCPUWizard

    For those saying Logic in XML is WTF....please provide a runtime configurable alternative.

    Lua.

  • blakeyrat (disco) in reply to TheCPUWizard
    TheCPUWizard:
    For those saying Logic in XML is WTF....please provide a runtime configurable alternative.

    This is exactly what JavaScript was designed to do.

  • hungrier (disco) in reply to Onyx
    Onyx:
    > Logic via XML? That’s a WTF all by itself, sure. But TRWTF is

    trying to embed an image right next to deeply nested XML... :rolleyes:

    Obviously they should have embedded it inside the XML.

  • Gaska (disco) in reply to TheCPUWizard
    TheCPUWizard:
    No matter the format, you are going to end up with deeply nested structures.
    Not if instead of writing abstract syntax trees in fully verbose way, you write actual code.
    blakeyrat:
    This is exactly what JavaScript was designed to do.
    No it wasn't. Lua was, however.
  • Gaska (disco) in reply to hungrier
    Comment held for moderation.
  • blakeyrat (disco) in reply to Gaska
    Gaska:
    No it wasn't. Lua was, however.

    Yes it was. So was Lua. Both languages were written for the same purpose. So was VBA.

  • Gaska (disco) in reply to blakeyrat
    blakeyrat:
    Yes it was.
    No it wasn't. JS was designed to run inside the web browsers and manipulate DOM elements. It just happens that because it's Turing-complete and interpreter is fast enough, it might work for embedded scripts in other applications too. Lua was designed for embedded scripts right from the start. VBA is a bit different - this particular implementation was designed to be embedded, but the language is straight descendant of Basic, which was meant as general-purpose.
  • TheCPUWizard (disco) in reply to blakeyrat
    blakeyrat:
    Yes it was. So was Lua. Both languages were written for the same purpose. So was VBA.

    I like Lua, so don't get me wrong....but using any of the proposed "languages" rather than a pure datastructure (independent of it being XML) puts constraints on the execution environment - which was my point.

    For example, it would be easier to implement an interpreter for the posted XML on an arbitrary machine in an arbitrary language than it would be to create a JavaScript interpreter that could be run inside of a Cobol program on a Mainframe from the last century.

    So, in this case going with a "data structure" rather than a "language" might be a WTF, but there are many potential unknowns.

  • CoyneTheDup (disco)
    Comment held for moderation.
  • Onyx (disco) in reply to CoyneTheDup
    Comment held for moderation.
  • blakeyrat (disco) in reply to Gaska
    Gaska:
    No it wasn't.

    Yes it was, and this conversation is quickly getting boring.

    Gaska:
    JS was designed to run inside the web browsers and manipulate DOM elements.

    If it was designed to manipulate DOM elements, why is it so goddamned awful at that? Why doesn't any (either!) of JavaScript's built-in libraries contain any helper functions useful for that purpose?

    What you're describing is what JavaScript was first used to do, not what it was designed to do. There's a difference.

    Gaska:
    It just happens that because it's Turing-complete and interpreter is fast enough, it might work for embedded scripts in other applications too.

    Of course. That's what it's designed to do.

    Gaska:
    Lua was designed for embedded scripts right from the start.

    Just like JavaScript was.

    TheCPUWizard:
    For example, it would be easier to implement an interpreter for the posted XML on an arbitrary machine in an arbitrary language than it would be to create a JavaScript interpreter that could be run inside of a Cobol program on a Mainframe from the last century.

    I actually don't think that's true. If you need to interpret this inside a COBOL program on a mainframe from the last century, you're in a world of hurt no matter what format it's in.

  • RaceProUK (disco) in reply to blakeyrat
    blakeyrat:
    Yes it was, and this conversation is quickly getting boring.
    No; JavaScript was created by Netscape for their Navigator web browser.
    blakeyrat:
    If it was designed to manipulate DOM elements, why is it so goddamned awful at that?
    Because DOM sucks donkey dick.
  • blakeyrat (disco) in reply to RaceProUK
    RaceProUK:
    No; JavaScript was created by Netscape for their Navigator web browser.

    Correct. How does that change anything I've said in this thread?

    We're not talking about who made it, or what it was first used for, but what it was designed to do.

    RaceProUK:
    Because DOM sucks donkey dick.

    Concur; but if JavaScript was designed specifically to deal with DOM, you'd think it'd have DOM somewhere in its libraries.

  • RaceProUK (disco) in reply to blakeyrat
    blakeyrat:
    Correct. How does that change anything I've said in this thread?
    If you can provide a reference that confirms JS was designed for logic-based config, then I'll concede; until then, I'll stick with what I've been able to find, which is that JS was created to be a lightweight scripting language to complement Java.
    blakeyrat:
    Concur; but if JavaScript was designed specifically to deal with DOM, you'd think it'd have DOM somewhere in its libraries.
    It does insofar as it was left to the browsers to implement; the problem is, Netscape and Microsoft had very different ideas on how DOM should work, and DOM usage wasn't standardised anywhere near quickly enough to avoid the colossal mess that, thankfully, is now usually hidden behind jQuery or similar.
  • Gaska (disco) in reply to blakeyrat
    blakeyrat:
    If it was designed to manipulate DOM elements, why is it so goddamned awful at that? Why doesn't any (either!) of JavaScript's built-in libraries contain any helper functions useful for that purpose?
    It was designed specifically for this purpose. I never said it was designed *well*.
    blakeyrat:
    [Lua designed for embedding] Just like JavaScript was.
    The best test for checking if some technology was designed for something is to make a very, very basic thing using this technology. Say, a script calling a host application function which prints "Hello World". In Lua, it's trivial - push function on stack, save to global, run script. How much setup is required in case of JavaScript?
  • Jaloopa (disco) in reply to Gaska
    Gaska:
    The best test for checking if some technology was designed for something is to make a very, very basic thing using this technology

    No that would be a way to check if some technology was designed well for something

  • Gaska (disco) in reply to Jaloopa
    Jaloopa:
    No that would be a way to check if some technology was designed well for something
    Note "very, very simple". Testing something on basic stuff is **TERRIBLE** test. However, developers usually focus on making some particular simple thing as simple as possible - usually the most important building blocks of the stuff your users will do. If something simple is simple to do, then it means the designers had it in mind.
  • TheCPUWizard (disco) in reply to blakeyrat
    blakeyrat:
    I actually don't think that's true. If you need to interpret this inside a COBOL program on a mainframe from the last century, you're in a world of hurt no matter what format it's in.
    1. Mainframes over 15 years old are alive and well in many parts of the industry.
    2. Look at the market for Rules Engines (often licensing for $100K or more per instance) for said machines and Cobol program
    3. [and the really relevant one] Do you honestly think that writing a full JavaScript environment [ala NodeJs] is not more work than writing a simple tree processor????
  • hiromasaki (disco) in reply to Onyx

    No, TRWTF is using u_int32 for temperature.

    Unless the temperature is being stored in Kelvin and the design specs are more than a couple months old...

  • Gaska (disco) in reply to hiromasaki

    There's no unsigned temperatures anywhere in the article.

  • dkf (disco) in reply to hiromasaki
    hiromasaki:
    Unless the temperature is being stored in milliKelvin

    FTFY<sigh>

  • Keiya (disco) in reply to TheCPUWizard

    This may all be true, but XML is still a terrible choice. An S-expression-like syntax might be a good choice.

    (* (* (+ (/ (& (baseNToInt 16 (regex ...)) 8388607) 8388608) 1)  ... ))
    

    still isn't exactly readable but it's a lot less terrible.

  • anotherusername (disco) in reply to Gaska
    Comment held for moderation.
  • mott555 (disco) in reply to hiromasaki

    If you want to use u_ints, find a high value not likely to be encountered in real life, and pick it as a special value to say "Numbers above this are actually sub-zero."

    temperature in Fahrenheit = x when x < 1000 temperature in Fahrenheit = 1000 - x when x >= 1000

    I know, I know, Evil Ideas Thread is elsewhere.

  • Jerome_Grimbert (disco) in reply to Gaska
    Gaska:
    If it was C++ templates rather than XML, I'm sure there would be people who would see it as a reasonable thing to do.

    Even a simple C would solve that problem, with union. Fill as int32_t, read as float, done. At worst, union of array of unsigned char and float, if the byte order still need to be reversed.

  • hiromasaki (disco) in reply to Gaska

    Oh, so there isn't... I missed that on the next line they manually start converting the u_int32 to float.

  • dkf (disco) in reply to anotherusername
    anotherusername:
    Sooo... JS was designed to manipulate data like XML?

    Ah, but DOM was “designed” to be fucking awful in all possible programming languages.

  • tarunik (disco) in reply to TheCPUWizard
    TheCPUWizard:
    1) Mainframes over 15 years old are alive and well in many parts of the industry. 2) Look at the market for Rules Engines (often licensing for $100K or more per instance) for said machines and Cobol program 3) [and the really relevant one] Do you honestly think that writing a full JavaScript environment [ala NodeJs] is not more work than writing a simple tree processor????
    Not *writing*, *porting* -- unless you're saying that such mainframes don't even have such niceties as a C compiler?

    :wtf:

  • Jaloopa (disco) in reply to mott555
    mott555:
    If you want to use u_ints, find a high value not likely to be encountered in real life, and pick it as a special value to say "Numbers above this are actually sub-zero."

    You could choose a number somewhere in the middle of the possible range, say 2147483647. You could then call this convention a "signed integer"

  • TheCPUWizard (disco) in reply to tarunik
    tarunik:
    Not writing, porting -- unless you're saying that such mainframes don't even have such niceties as a C compiler?

    Many do not. In other cases where they exist, they are not allowed for Line of Business code [typically mandated to be COBOL].

  • tarunik (disco) in reply to TheCPUWizard
    TheCPUWizard:
    Many do not.

    :wtf: And retargetable C compilers have been around for how long now?

    TheCPUWizard:
    In other cases where they exist, they are not allowed for Line of Business code [typically mandated to be COBOL].
    A script interpreter isn't Line of Business code...

    (Anyone who thinks otherwise needs to be hit with a Dragon-book-sized cluebat, because interpreter innards are a classical CS topic i.e. not something COBOL-only ex-accountants should ever meddle with!)

  • TheCPUWizard (disco) in reply to tarunik
    tarunik:
    A script interpreter isn't Line of Business code...

    (Anyone who thinks otherwise needs to be hit with a Dragon-book-sized cluebat, because interpreter innards are a classical CS topic i.e. not something COBOL-only ex-accountants should ever meddle with!)

    LOB code is ANY code that if is magically disappeared in an instant would have any effect on business operations.

  • tarunik (disco) in reply to TheCPUWizard
    TheCPUWizard:
    LOB code is ANY code that if is magically disappeared in an instant would have any effect on business operations.

    Does that, by transitive extension, include the OS, runtime libraries, bootloader, and hardware drivers? Because those certainly aren't written in COBOL!

  • Zylon (disco) in reply to dbenzhuser
    dbenzhuser:
    TRWTF is an 11.3 MB picture in the article.
    Hotlinked from Wikimedia, no less.

    You'd think the people who contribute to a site dedicated to mocking WTFs would exercise some care in not committing WTFs themselves, but noooooooooooo...

  • HardwareGeek (disco) in reply to tarunik
    tarunik:
    (Anyone who thinks otherwise needs to be hit with a Dragon-book-sized cluebat, because interpreter innards are a classical CS topic i.e. not something COBOL-only ex-accountants should ever meddle with!)

    COBOL-only ex-accountants should definitely meddle in the affairs of dragons.

    Filed under: [spoiler]crunchy, taste good, ketchup[/spoiler]

  • CoyneTheDup (disco) in reply to Onyx
    Onyx:
    You didn't have to go that far...

    LOL. I just remembered I'd seen it somewhere. I tried to search on Google, but didn't find the TD :wtf: so I went with the GitHub one. Here, he was just asking; there, it's published as a public project.

    Truly amazing. I swear, some of these zealots would use a sledgehammer to fix a contact lens.

  • Gaska (disco) in reply to anotherusername
    anotherusername:
    Sooo... JS was designed to manipulate data like XML?
    Yes. In a browser. I love how you hid that part of quote behind ellipsis. Reminds me of a recent country-wide shitstorm we had due to all the major TVs misquoting one politician in similar way...
  • Gaska (disco) in reply to Jerome_Grimbert
    Jerome_Grimbert:
    Even a simple C would solve that problem, with union.
    Undefined behavior ahoy!
  • Tsaukpaetra (disco) in reply to dbenzhuser

    I was wondering WTF it was taking so long to load what is essentially supposed to be a text article... And this time I couldn't blame it on the company blocking yandex.st!

  • Eldelshell (disco) in reply to Nprz
    Nprz:
    Reminds me of back when browsers would fail to download images, so you could right-click and do "Show Picture" (or configure the browser to not auto-load the image).

    Not trying to be pendantic but:

    [image] [image]
  • christop (disco)

    Lisp, anyone? (I mildly refactored it to remove redundancies).

    (let* (
           (row-oid (get-row-oid ".1.3.6.1.4.1.2011.2.217.1.4.1.1.6"))
           (regex "(?:0x)?([0-9a-fA-F][0-9a-fA-F])\s*([0-9a-fA-F][0-9a-fA-F])\s*([0-9a-fA-F][0-9a-fA-F])\s*([0-9a-fA-F][0-9a-fA-F])")
           (replacement "%4$s%3$s%2$s%1$s")
           (oid (base-n-to-int (regex regex row-oid replacement) :base 16)))
     (*
      (1+ (/ (boole-and oid 8388607) 8388608))
      (ash 1 (- (boole-and (ash oid -23) 255) 127))
      (if (= (boole-and (ash oid -31) 1) 1) -1 1)))
    

Leave a comment on “Once You Eliminate the Impossible…”

Log In or post as a guest

Replying to comment #:

« Return to Article