In Log4J WTF news today…
-
@Arantor said in In Log4J WTF news today…:
Or that they’re not secretly a weird AI in disguise.
@Tsaukpaetra's disguise isn't very secret.
-
@Luhmann said in In Log4J WTF news today…:
@BernieTheBernie said in In Log4J WTF news today…:
just take a look at the fornt page:
the what?
-
@Bulb said in In Log4J WTF news today…:
We already had Singletons: Solving Problems You Didn't Know You Never Had Since 1995.
Singletons do solve a real problem - order of initialization of global variables. It's a wrong solution (the right one is to not have global variables), but a solution nonetheless.
-
@Gąska It's not singletons, it's the lazy well-known instance getters that do. And what the article is mainly about is that it makes no sense to enforce having a well-known instance in the class itself, because it limits your options without giving you anything in return.
-
@boomzilla
@trithne said in IBM's JSONx, or how to represent JSON in XML:That's it, I'm out. I can't do this anymore, going to raise turtles in the Amazon or something less stupid than software.
I feel like this is the running theme here.
-
@Gąska said in In Log4J WTF news today…:
@Luhmann said in In Log4J WTF news today…:
@BernieTheBernie said in In Log4J WTF news today…:
just take a look at the fornt page:
the what?
Good catch.
-
-
@Bulb said in In Log4J WTF news today…:
cheap joke
<abbr title="very obviously 'shopped">¹</abbr>to me.A cheap joke is worth only so much battle with the
.
-
-
@HardwareGeek said in In Log4J WTF news today…:
@Arantor said in In Log4J WTF news today…:
Or that they’re not secretly a weird AI in disguise.
@Tsaukpaetra's disguise isn't very secret.
I have been summoned, and so I appear...
-
@homoBalkanus said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
But IBM does not have a mind of it's own.
Paging @Watson
They've gotta catch me first.
-
@Watson are you on a mission from God?
-
@loopback0 said in In Log4J WTF news today…:
@Arantor said in In Log4J WTF news today…:
Or that they’re not secretly a weird AI in disguise.
I misread this as
Weird Alas if he's given up with parodies and now just writes JSON as XML.JSONx parodies itself just fine.
-
@Bulb said in In Log4J WTF news today…:
@Gąska It's not singletons, it's the lazy well-known instance getters that do. And what the article is mainly about is that it makes no sense to enforce having a well-known instance in the class itself, because it limits your options without giving you anything in return.
Problem is that you are talking about piece of negative opinion based on observation of some "positive" opinion... in other words, third-hard account.
I recommend reading the foreword for the later editions of the GOF books (usually it's free on Amazon). They kinda... address the fact that the whole industry just completely missed the point
and created an insane cargo cult. They did not say that directly, though, probably because of the sweet sweet 
from the cargo cult bible sales.Of course, considering that the very purpose of Design Pattern is to facilitate clear communication and understanding between humans, it's a colossal failure.
-
@Kamil-Podlesak said in In Log4J WTF news today…:
whole industry just completely missed the point
I would say the C++ community, or at least it's ‘modern C++’ part, and some other language communities, avoided it. But the Java community definitely did.
-
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
whole industry just completely missed the point
I would say the C++ community, or at least it's ‘modern C++’ part, and some other language communities, avoided it. But the Java community definitely did.
might have avoided the cargo cult, but they still mostly miss the point.Also, I disagree - the late 1990s C++ style was very into Design Patterns.
-
@Kamil-Podlesak said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
whole industry just completely missed the point
I would say the C++ community, or at least it's ‘modern C++’ part, and some other language communities, avoided it. But the Java community definitely did.
might have avoided the cargo cult, but they still mostly miss the point.… true.
Also, I disagree - the late 1990s C++ style was very into Design Patterns.
It depends on what codebase you worked with, and it rarely went anywhere close to the level of retardery common in Java.
-
It's been said that explicitly-coded Design Patterns (e.g., "We will have a Factory here and a Flyweight there, and a ...") arose or were adopted to address language limitations (in that, in a good language, the "right way" to do something would be the "obvious" way to do it and wouldn't need so much memorised ritual).
I guess Java ... had limitations.
-
@Watson said in In Log4J WTF news today…:
We will have a Factory here and a Flyweight
Has anybody ever used a flyweight outside of GoF?
-
@topspin very likely without realising it. I’ve certainly done things that resemble it for memory conservation reasons even if I didn’t explicitly go full bore into their reference implementation kind of thing.
-
@topspin said in In Log4J WTF news today…:
flyweight
What even is that
googles
Doesn't basic stuff like static 'translate ID to description' functions fall under that category? Though I tend to quickly move to storing pointers instead of IDs.
-
@PleegWat it’s more “I have a central store of things that everything uses by reference”, though yes id->description in a centralised way could be. The key point is that you’re consciously deduplicating instances of objects by keeping a single repository of instances (usually application wide) and letting everything reference those in a “it’s not global because globals are bad, m’kay, but it’s basically globals”.
-
@Arantor said in In Log4J WTF news today…:
@PleegWat it’s more “I have a central store of things that everything uses by reference”, though yes id->description in a centralised way could be. The key point is that you’re consciously deduplicating instances of objects by keeping a single repository of instances (usually application wide) and letting everything reference those in a “it’s not global because globals are bad, m’kay, but it’s basically globals”.
Mutable shared state is bad, immutable shared state is fine.
But whenever I have a shared pointer to something I don't really think "omg flyweight", so that's probably why it registers as "nobody ever used that" to me.
I guess Java interned strings are flyweights, then.
-
@Arantor Yeah, we don't really do it dynamically. It's always static lookups or configuration-based stuff. Values either don't get duplicated enough or don't live long enough for it to be worth it.
In ancient history we did this for database values - instead of varchar columns in our main fact tables we'd have IDs into a separate string lookup table. We got rid of it because it was horrible to query.
-
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
whole industry just completely missed the point
I would say the C++ community, or at least it's ‘modern C++’ part, and some other language communities, avoided it. But the Java community definitely did.
might have avoided the cargo cult, but they still mostly miss the point.… true.
Also, I disagree - the late 1990s C++ style was very into Design Patterns.
It depends on what codebase you worked with, and it rarely went anywhere close to the level of retardery common in Java.
Pfft, ManagerManagerFactoryFactoryInterface is not retardery. It's a capital offense and the perpetrator should be dragged outside and shot. And I've seen one of those in live production code.
That said, Java people have significantly reduced the utter retardery a lot the last decade.
-
@topspin said in In Log4J WTF news today…:
@Arantor said in In Log4J WTF news today…:
@PleegWat it’s more “I have a central store of things that everything uses by reference”, though yes id->description in a centralised way could be. The key point is that you’re consciously deduplicating instances of objects by keeping a single repository of instances (usually application wide) and letting everything reference those in a “it’s not global because globals are bad, m’kay, but it’s basically globals”.
Mutable shared state is bad, immutable shared state is fine.
But whenever I have a shared pointer to something I don't really think "omg flyweight", so that's probably why it registers as "nobody ever used that" to me.
I guess Java interned strings are flyweights, then.
Yes, basically it's very common. I would even agree that assigning one universal global term for the concept is quite useful (as long as everyone knows that term, of course). But the description completely hides it behind some factories and instances and whatnot.
-
@Carnage said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
whole industry just completely missed the point
I would say the C++ community, or at least it's ‘modern C++’ part, and some other language communities, avoided it. But the Java community definitely did.
might have avoided the cargo cult, but they still mostly miss the point.… true.
Also, I disagree - the late 1990s C++ style was very into Design Patterns.
It depends on what codebase you worked with, and it rarely went anywhere close to the level of retardery common in Java.
Pfft, ManagerManagerFactoryFactoryInterface is not retardery. It's a capital offense and the perpetrator should be dragged outside and shot. And I've seen one of those in live production code.
That said, Java people have significantly reduced the utter retardery a lot the last decade.One important thing (I repeat it over and over again, but it needs to be said): most of the (in)famous cases of FooManagerFactoryBarFactoryInterface has nothing to do with "Design Patterns", it's a completely different
- namely, Java's lack of metaprogramming. It got a lot better with Java 8, but only to the extent that most of these crutch classes are now anonymous (lambdas). But not completely, because they still need to implement some interface. Named interface... and quite often there is no meaningful name.
-
@Kamil-Podlesak said in In Log4J WTF news today…:
@Carnage said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
whole industry just completely missed the point
I would say the C++ community, or at least it's ‘modern C++’ part, and some other language communities, avoided it. But the Java community definitely did.
might have avoided the cargo cult, but they still mostly miss the point.… true.
Also, I disagree - the late 1990s C++ style was very into Design Patterns.
It depends on what codebase you worked with, and it rarely went anywhere close to the level of retardery common in Java.
Pfft, ManagerManagerFactoryFactoryInterface is not retardery. It's a capital offense and the perpetrator should be dragged outside and shot. And I've seen one of those in live production code.
That said, Java people have significantly reduced the utter retardery a lot the last decade.One important thing (I repeat it over and over again, but it needs to be said): most of the (in)famous cases of FooManagerFactoryBarFactoryInterface has nothing to do with "Design Patterns", it's a completely different
- namely, Java's lack of metaprogramming. It got a lot better with Java 8, but only to the extent that most of these crutch classes are now anonymous (lambdas). But not completely, because they still need to implement some interface. Named interface... and quite often there is no meaningful name.The cases I've seen of that have been deep misunderstandings of one or another design pattern. They were always mostly unnecessary and could have been solved in much better ways with less code.
Most of the time, the lambdas are just one of the java.functions ones, and it's considered best practice in lots of places to not create a functional interface if there already is one that can do the job in there.
Then there is of course the silly Thread/Runnable lambdas.
Having generic functional interfaces I can deal with, but using something with a misleading name and completely different purpose like that is just wrong.
-
-
The funniest part about this whole log4j debacle is that npm has one of these weekly.
-
@Carnage said in In Log4J WTF news today…:
The funniest part about this whole log4j debacle is that npm has one of these weekly.
And somehow this is both tolerated and normalised.
-
Clearly this whole debacle could have been avoided if people didn't continue to insist on using unsafe languages.
-
@cvi said in In Log4J WTF news today…:
Clearly this whole debacle could have been avoided if people didn't continue to insist on using unsafe
languagesdevelopers.FTFY.
-
-
-
@topspin said in In Log4J WTF news today…:
Has anybody ever used a flyweight outside of GoF?
Yes. In some cases, it can be a massive performance win. Consider splitting a long text into words (where you don't care too much about the locations of those words, just the sequence). In that case, using flyweights for the strings of each word greatly reduces the number of allocations required and is an excellent optimization.
-
-
@Kamil-Podlesak said in In Log4J WTF news today…:
It got a lot better with Java 8, but only to the extent that most of these crutch classes are now anonymous (lambdas). But not completely, because they still need to implement some interface. Named interface... and quite often there is no meaningful name.
Most often Function or BiFunction from java.util.function works well enough. Too bad there's no standard TriFunction or QuadFunction.
-
@LaoC said in In Log4J WTF news today…:
It's funny because the very reason we have this crisis is because people patched the vuln in Log4J 1.4 without looking at what's in the patch!
-
@Gąska said in In Log4J WTF news today…:
Too bad there's no standard TriFunction or QuadFunction.
Nothing that consumes them either, and the types start to look a bit ferocious.
-
@Bulb said in In Log4J WTF news today…:
@dkf It is almost always machine generated, because who in their right mind would write XML by hand. But it still wastes space by repeating the prefix all over.
Have you ever had to maintain a couple hundred lines of yaml? I'd happily take XML over it anyway. With a modern tool and a well written xsd it's easier than code.
-
@DogsB even with a bad tool and no xsd I find XML easier to read than YAML. Probably because there's only one syntax to learn.
-
I find YAML pretty easy to use for my config files, I even made up a little query language for error-bot that can be represented nicely in YAML:
It seems to diff/merge easier than even JSON, mostly due to the lack of trailing commas in arrays.
I'm sure you can
enough to make it a nightmare but IME it's fine if you don't do that.
-
@error LOL at the personae non gratae.
-
@error said in In Log4J WTF news today…:
It seems to diff/merge easier than even JSON
So does literally every other format on Earth aside from PDF. Using JSON as your baseline here is like using C++ as a baseline of simplicity. Which I've seen people do so it's not entirely sarcasm.
-
@Gąska out of morbid curiosity, what was the comparison to?
-
@Gąska said in In Log4J WTF news today…:
@error said in In Log4J WTF news today…:
It seems to diff/merge easier than even JSON
So does literally every other format on Earth aside from PDF. Using JSON as your baseline here is like using C++ as a baseline of simplicity. Which I've seen people do so it's not entirely sarcasm.
That all depends on your diff/merge engine. A merge engine which understands JSON syntax would do better at it than a simple line-based one, even if the JSON is pretty-printed.
The in-house merge engine used by our in-house source control system has special handling for various formats. For example, if two branches both add a line at the same point in a C function, this is a conflict which is presented to the user. However, if two branches both add a new function definition in the same location, this conflict is resolved automatically.
-
@error said in In Log4J WTF news today…:
I find YAML pretty easy to use for my config files
It's not too bad for config files, but it's pretty awful for some of the other things that JSON and XML are used for. In particular, those two both canonical serializations and are strictly single-rooted trees; YAML isn't. And YAML has a lot of variants too. That's not too big a problem when you're writing configs — you just write what your tools consume — but in applications that require document exchange and validation, YAML's a PITA. And can describe almost arbitrary directed graphs.
-
@JBert said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
Even setting verbosity per component ends up not being used in practice, because when debugging, one rarely knows for sure which components they need anyway.
It's nifty though if you have some middleware which can generate DEBUG messages but you want to keep the rest of the application generating just INFO messages.
I also frequently have 1 component which retrieves the application version and logs it on boot, and since that logs at INFO level it is nice to configure that independently from the level the rest of the application runs at.
One of the projects I've worked on made extensive use of per component configuration, even setting up a separate TRACE level logger for one particular component
-
@hungrier said in In Log4J WTF news today…:
One of the projects I've worked on made extensive use of per component configuration, even setting up a separate TRACE level logger for one particular component
The good thing about using a logger (as opposed to just printing to stdout) is that you can get lots of detail in some parts of the application without rebuilding the whole thing or getting lots of detail from other parts. Some people never make use of that, but it is genuinely useful.
Bitbucket
