• Zed (unregistered)

    And yet, if we were to fire these people into the sun, we would not be hailed as heroes.

    Life is strange.

  • LZ79LRU (unregistered)

    I like this. It makes my inner gremlin smile.

  • (nodebb)

    What is especially disconcerting is the number of requests for modern strongly-typed languages like C# and Java to make it easier to operate on objects like people know them in JS, essentially maps/dictionaries. My theory is that JS has become too popular, and to many devs out there it is the "natural" way of doing things, and when they encounter a strongly-typed language, they view the rules as an annoyance.

    Granted, it's a different phenomena than what is described in this article, but still - as an industry, we have a long way to go to educate devs about... well everything, really.

  • LZ79LRU (unregistered) in reply to Mr. TA

    Map<String, Object> / Dictionary<String, Object> / std::map<std::string, void*> Just saying.

    If you really wanted to do this you could have from day one in most languages. Just make a class with one of these and implement a get method to hide it.

  • trainbrain27 (unregistered) in reply to Zed

    The problem with firing someone into the sun is that it requires massive ∆v.

    Composting is the green solution, and the BOFH has evolved from the ineffective quicklime and carpet to the Russian solution, which they acquired from the Czechs in a Special Defenestration Operation.

  • (nodebb) in reply to Mr. TA

    but still - as an industry, we have a long way to go to educate devs about... well everything, really.

    Except that the said industry has spent the last quarter of a century, perhaps a bit more, trying to make it so that any uneducated ... oik ... can pretend to be a developer.

  • Brian (unregistered)

    Reminds me of a guy I used to work for. He had this homebrew C++ library that included, amongst other things, "generic" container classes that stored everything as a char*. So you could put anything in and get anything out, completely ignoring all that annoying compile-time type checking. From some of the other operations and function names in the lib, it was clear he was basically trying to turn C++ into PHP.

    Oh, did I mention this was the CTO of the company, and thus this lib was the foundation of the entire codebase? Suggestions to switch things over to using the STL were not favorably received.

  • TheCPUWizard (unregistered)

    @Steve & TA...... Far too true... As someone "in the game" for 50 years, I fear that Software Engineering is a fading and nearly lost art/science....

  • Gonzo (unregistered)

    Sorry, but this article is a bit pointless.

    For starters, "there are many libraries" - twenty years ago, really?

    Second, "tedious" - yes it is, but have you been also telling this to every single developer who is religious preaching to use getters and setters everywhere? That's exactly what it is.

    I do think anyone here knows enough about this code or project to make any educated statement on how good or bad that code is. Does it sound a bit odd? Yes, it may. Does that necessarily make it "bad code"? No, not necessarily. Is it a WTF in the sense of this page? Definitely not.

    Sorry, poor article :)

  • Gonzo (unregistered) in reply to Gonzo

    *"I don't think"

  • (nodebb) in reply to Gonzo

    Does that necessarily make it "bad code"?

    Yes. It's bad for the simple reason that code to do simple things, read/write attributes of an object, is hard to read. If I were given a library and the sample code to use it looked like this, the first thing I would do is write a wrapper that allowed me to access it in the native way.

    This article is literally about someone that wrote a wrapper to make a simple API complicated. That's a WTF.

  • (nodebb) in reply to Zed

    And yet, if we were to fire these people into the sun, we would not be hailed as heroes

    I could not. But as soon as the main genius behind this idea left the team (not the company, unfortunately) I fired the UniversalStream into a very, very distant star, and there was much rejoicing.

  • (nodebb) in reply to LZ79LRU

    std::map<std::string, void*> Just saying. If you really wanted to do this you could have from day one in most languages. Just make a class with one of these and implement a get method to hide it

    Remy shortened my original submission - which is good, because it was far too long (but maybe also bad, because even just the header file for UniversalStream was rich in WTFs). Spoiler: UniversalStream ACTUALLY hid a std::map. This did not make it "right", since this part of the application never needed to treat data structures as dictionaries. So, things that were straightforward (and type-safe) with DTOs became needlessly complicated, error-prone and impossible to debug. Furthermore, it was not just a map of void pointers ... it was much, much worse... if Remy allows me, I'll post the full header file. Or maybe Remy is saving it for a rainy day?

  • (nodebb) in reply to Gonzo

    For starters, "there are many libraries" - twenty years ago, really?

    I don't know what Remy meant here, but hey, probably even the "evil" C macros would have done a better job here (and unfortunately, that application used them every other day, but that's another sad story).

    Second, "tedious" - yes it is, but have you been also telling this to every single developer who is religious preaching to use getters and setters everywhere? That's exactly what it is

    The getters and setters were not the only "tedious boilerplate" part (and I'll reveal you a secret, that I did not tell even to Remy: some DTO classes did not even have getters and setters because they had - gasp! - public data!). There was also the serialization code (remember that C++ lacks reflection), some dump code for debugging reasons, and some other stuff that's better left unsaid (I cannot say too much: even mangled, the code may be recognizable, even if I did not disclose the exact year, the type of project, the 3rd party libraries used, etc). That was "tedious" from the POV of the Great Genius who created UniversalStream. From my POV, the "tedious boilerplate" code was just a few lines for each DTO class, with huge benefits: short, readable, type-safe, descriptive and meaningful BUSINESS LOGIC CODE. That should be the purpose of classes. Instead, to save a few keystrokes here and there, the Genius create a big unmaintainable monster, effectively moving the boilerplate to the BUSINESS LOGIC, spreading it like a virus.

    So yes, this is a WTF not unlike writing TypeScript but 90% data types are "any". Or, more appropriately, filling a C# application with "new Tuple<string, string, string, string, string>"

    • and yes, unfortunately, I've seen both, and not only once :(
  • Wilderness (unregistered)

    Reminds me of the folks who thought there were too many video cable standards. They created one to consolidate them all...but just ended up making another video cable standard.

  • Gonzo (unregistered) in reply to Jaime

    You think this code is bad and hard to read? Have you heard of Spring or any of the other miraculous frameworks of any language of your choosing? This code may not be great but it's not more a WTF than the vast majority of what's out there.

  • Gonzo (unregistered) in reply to StefanoZ

    Stefano, I am afraid I can only go by what the article mentions and nothing there really stands out as "WTF". If there are other details, that may change the story of course, but that's something I cannot comment on.

  • Your Name (unregistered)

    TF? They have a method called stream.GetUniversalItem, but that doesn't actually return an UniversalItem?

    Library code is supposed to make the users life easier. Fuck code elegance and academic linting ("The spelling of the method does not follow conventions")

  • FTB (unregistered) in reply to LZ79LRU

    @LZ79LRU "std::map<std::string, void*>"

    You'd throw a void* into a std::map?

    That comment deserves it's own submission to TDWTF.

  • FTB (unregistered)

    Just use public members and add a "looksOK()" method the check the consistency of the data. Call it often and log any records that don't pass the sniff test.

  • LZ79LRU (unregistered) in reply to StefanoZ

    There is NOTHING that is EVER going to make std::Map<string, void*> right. I was just pointing out that if someone really wanted to implement a Javascript like monstrosity the tools were always there.

    Not that I mind, mind you. As far as I am concerned GOTO was newer harmful. Which by the way is a metaphorical statement of my view that good tools should offer maximum flexibility even if it comes with risks of misuse rather than being padded for our own protection against our self. We are engineers, not children.

  • hwertz (unregistered)

    Sure looks like a WTF to me! Going from (slightly cumbersome but at least not TOO verbose) getters and setters to considerably more verbose list of constants, having to add the generic items in the right order, the "magic constants" 0, 1, 2? I mean, having code end up like that in the bowels of the function might not be a WTF, but using that as an external interface sure is. Then, switching from "magic integers" to strings for additional options? Seems like an additional WTF. But I do my programming in Python, so I'm used to having a clean interface even if the internals may be messy.

    Having had to deal with some NodeJS code recently... ugh, Javascript. I don't have anything more to say about that.

  • (nodebb) in reply to LZ79LRU

    I was just pointing out that if someone really wanted to implement a Javascript like monstrosity the tools were always there.

    Sorry, I misunderstood that it was a reply to Mr. TA. Anyway, dedicated syntaxes (such as dynamic in C#) are - or at least they look - much more elegant than maps. Of course, when you throw type safety out of the window, there is very thin line between "elegant" and "nightmare" ...

    We are engineers, not children

    After 20 years of career, I'm starting to have dobuts about that :D

  • LZ79LRU (unregistered) in reply to StefanoZ

    I don't know how you get those quotes to work like that. So just assume this is my answer to the last sentence. And that answer is simple:

    I would agree with you over that, or maybe argue against it, I am not even sure, not even in jest.

    But right now I am looking up ideas on how to create a dynamically generated C# class using ExpandoObject to have a class with a hidden Dictionary<string, object> and a bunch of accessors (property that has a get) all generated on runtime based off a KeyValuePair<type, string>[] passed to a construction method in a separate Factory class which will also generate a dynamically produced enum.

    The resulting dynamic class generation during runtime will (and I say WILL, not would, I am writing this madness for fun) have a hidden dictionary for members and dynamic properties which can only be accessed from the rest of the code by using reflection to loop through the enum, find the matching item to the property name you want and than using reflection to find the property in the class whose index in the list of all properties matches the enum as int.

    So I guess I am a bit like a child. A mad, insane child that has gazed into the abyss for a tad too long. And if Dijkstra or anyone else comes to try and take my toys I intend to use my tentacles in anger.

    :)

  • Daniele (unregistered) in reply to LZ79LRU

    We are engineers, not children

    20 years ago I would have agreed. These days I am (mostly) not sure

  • meclizine 12.5 mg (unregistered)

    generic meclizine http://meclizinex.com/# generic meclizine 25 mg

Leave a comment on “Universal Stream”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article