Why do you need cookies (and therefore cookie compliance JS)?
Readit Newspalata commented on · Posted by u/dreadsword
Well I guess I am not clear enough. Naming stuff is a normal human habit, maybe even why we have language? So we can agree on that, it's helpful.
But you say it yourself, a thing is called different in another language, so the thing is bigger then the word. But everyone can handle it better in his own head and in communication with a word for it.
I guess my usual grief is that any kind of excessive celebration and ceremony comes down to some kind of brainwash. Which mostly affects newbies and cultists.
The article for example isn't overtly critical on singletons, while past design pattern writings often heavily disregarded the use of it. So we don't just always reiterate the good, but also the bad.
I don't mind the celebration and ceremony as long as they don't bother me personally. I wouldn't fight against the existance of a PatternConf, I just wouldn't go :-).
I've had some debates with junior devs who really wanted to enforce their newly-learned patterns, and my experience there is that passed a certain point, there is no convincing anymore: if they really insist about overengineering something with their newly-learned concept and the hierarchy doesn't allow me to prevent them from doing it, anyway they will do it. So instead of fighting I just let them, and if it turns out to be a waste of time in the end... well that's not my problem: I was not in a position to prevent it in the first place.
It's not only patterns though: some juniors have a way to try to use every exciting framework or library or tool they just discovered.
I have mixed feelings about this.
I think Julian Assange once said he would refer to things in discussion just as "Tomato" (or similar), in discussion to have a shortcut for something unnamed with some meaning. We do this all day in programming, we give a complex component a name and it means a lot more then just the actual word. The problem is that this specific meaning is often not universal, it's contextual.
If you take a hammer, an integer and design patterns, the latter is the least universal thing. They depend on domain, context and conventions, and can change quite a lot depending on the language. Removing hammers and integers from the world would cause collapse, removing design patterns would do almost nothing.
I guess the active celebration of design patterns as a catalogue of general wisdom is my primary issue here. I'd welcome any project/team/company that maintains a catalogue of their individual "patterns". But a universal source of truth has too much bible flavor to me. (Oh it also dictates OOP by default which renders it's inherent "wisdom" completely useless in many languages)
I feel like we're talking past each other. I tend to agree with you, I don't like having a "bible" and "celebration of design patterns as a catalogue of general wisdom".
But formalising concepts with words makes sense. If your company maintains a catalogue of their patterns, and someone happens to know that this specific pattern is usually called a "singleton", I would find it weird to call it a tomato.
Some patterns have different names in different contexts or languages, and that's fine. I don't find it weird to have a discussion around "in this language there is this pattern that they call X, does that ring a bell for you working on that other language? The idea is [...]", and maybe the answer is "yep we have it too" or "oh, we call that Y, but that's pretty similar".
The other thing that design patterns allow, is to learn pitfalls, applications and other attributes about them.
To keep in your analogy, if you have a 3KG naildriver with a 2m handle you'll quickly find out that driving nails into a drywall with that leaves you with no wall. And that it's a bad idea to use a "Naildriver" to drive these "spiralled-slothead-nails" (aka screws) into wood.
But with a common language, such as design patterns, you can easily learn where they are good, what their limits are, in what cases other patterns fit better, and what pitfalls to avoid and so on.
If I search the web for "why is it so hard for my naildriver to drive in spiralled-slothead-nails" I'll get zero results. But when I search for "why is it hard to hammer in a screw" I'll get good results. May sound like a silly example, but for me that sillyness illustrates how obvious designpatters should be.
I totally agree with that!
And it doesn't mean at all that everybody should learn the whole encyclopedia of tools by heart. But having it formalised somewhere is useful: as soon as someone tells me "what you're trying to do sounds like this design pattern", I can start searching and reading about it.
Of course if that someone tells me "you suck, you should know that there is a design pattern for that because you should read about design patterns every night before you go to sleep", it will be different :-).
You point out the cultural issue that this creates and sweep it under the rug, violently.
The thought model complicates the process of writing new code, "what pattern do i need here?" and the perception of existing code, "oh this is pattern X, why isn't that communicated clearly?". The truth is that design patterns are at best stagnant in quality and quantity over time (GoF is over 30 years old!), but the quantity and quality of problems is infinite.
I've thought in patterns quite some time in my early career. With my colleague back then everything was an pattern and we were kind of in sync with that approach. But it quickly falls apart if you have peers that are less try hard on it. You can spend days, weeks, months to study design patterns and then have to explain it to someone in 5 minutes that simply doesn't care. I can't blame anyone to not care, so that has to be accounted for.
I think the common language argument is tempting, but also too stressed. Good and useful programming knowledge is bound by reality. An integer is a indisputable thing that is always useful. A "singleton" is just a fancy rephrasing of "global state".
I did not mean "everybody has to learn the vocabulary". I meant the opposite, actually: it's fine not to know the word for the tool (I don't enjoy reading about patterns just to learn about patterns, it's not my thing at all).
Say I build a tool that makes it easier for me to drive a nail and call it a "Naildriver". If I show it to a colleague, they may be able to tell me "oh, this is generally called a hammer!". Maybe they will even tell me how I may improve my hammer, because they happen to like to learn about hammers in their free time. Or maybe now that they said it's a known concept, I will enjoy reading about hammers online (doesn't mean I will now read the entire encyclopedia of tools).
The fact that there is a name for the concept ("it's called a hammer") does not say you have to know the word. It's just useful to have a word for it, because then we can reference it in discussions and share knowledge about it more easily.
I find that the more senior you become, the less you rely on software design patterns.
Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more complexity than they would have created had they not used design patterns.
There are situations where design patterns may be useful but they're much more rare than most people think. A lot of juniors seem to think that every problem requires them to apply a design pattern from their toolbox. They try to frame every problem within the constraints of design patterns that they know. This can create problems.
In fact, there are many coding patterns which are far simpler than 'design patterns' and much more useful, but nobody talks about them because they're too trivial to discuss. For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I use it literally ALL the time. The idea of storing intermediate state in some kind of HashMap is a game-changer IMO but there's no name for that pattern of coding. In general, knowing what data structure is most appropriate for various scenarios is a game changer... But still, don't abuse. Basic data structures like arrays are fine most of the time.
Anyway, it's good to absorb the wisdom behind some design patterns but you should not try to fit every problem to them and dont say stuff like "For this problem, I applied Design Pattern X" - If you do, senior engineers will know you're a junior. If you use a design pattern correctly, it will probably not look exactly like in the textbook. It's kind of hard to give it a name. It may be a mix of patterns. It's the principle that counts. Reality is too complex for rigid design patterns.
On the other hand, some design patterns are too common and obvious to deserve a name. For example, the factory pattern is super common... I use it all the time but it's so basic and obvious that I will sound like a total noob if I go around calling my function "socket factory pattern"... I will call it "Utility function to obtain a socket" or something. I will never refer to it as a factory pattern, it's a bit cringe.
I see it as a common vocabulary to talk about tools. It's simpler to say "I made a singleton" than to describe it.
Just like we have words for a nail, a screw, a hammer. If you had to say "I used a tool that I find works well with nails", that would be annoying and ambiguous.
Now of course, if you quickly screwed something with your swiss-army knife and a junior came and told you that this is wrong, because you should always use a proper screwdriver, and therefore you should rent a car and drive 30min to go buy it right now, you would kindly tell them to fuck off. Doesn't mean that there is no value in the concept of a screwdriver itself.
palata commented on Australia begins enforcing world-first teen social media ban reuters.com/legal/litigat... · Posted by u/chirau
My takeaway is that jfindper is saying that seatbelt laws had a justification that does not have a parallel with this action regarding social media.
IDK if this is how they would say it, but I think argument for seatbelts is that there is minimum disruption to usage, there is limited revocation of other rights, and the societal benefit is large and pretty unambiguous.
The idea that I have to give up privacy, expose myself to additional risk (by having my identity logged), increase the chances that mentally susceptible people will have more exposure to fraud in order to get a solution that is not clear on how effective it will be makes the parallel a bit academic, if not an out right straw man.
> I think argument for seatbelts is that there is minimum disruption to usage, there is limited revocation of other rights, and the societal benefit is large and pretty unambiguous.
Said like this, it looks to me that it has a parallel with social media.
> The idea that I have to give up privacy
You don't have to, though.
> expose myself to additional risk (by having my identity logged)
It doesn't have to be, we can have privacy-preserving age verification. Now we could discuss the specific implementation, but in general that's feasible.
> increase the chances that mentally susceptible people will have more exposure to fraud
It's not enough to say it: is it actually the case? You can already get phished by trying to access a social network, how does that make it worse? I don't think it's obvious. While the problem with kids and social media is, at this point, very well documented.
> if not an out right straw man.
I, for one, think it's an interesting experiment. All the arguments above could be used against making cigarettes illegal for children. Yet I am very convinced that making cigarettes illegal for children is the right choice.
palata commented on Australia begins enforcing world-first teen social media ban reuters.com/legal/litigat... · Posted by u/chirau
> It's very unfortunate. As a parent, I feel like it requires regulation at the national level because I can't win against Meta (FB, Insta), Google (Youtube), Snapchat and TikTok.
Sorry, but this just isn't the case. I have children very much in the target age here, and they only have a passing understand of what social media even is due to us explaining how unhealthy it is to them.
It's unfortunate you feel incapable of achieving the same, but abdicating your responsibility as a parent to the state isn't the answer.
Yes, let's allow cigarette manufacturers to target children, and let's the capable parents teach them. Same for porn, alcohol, drugs. If your kids have issues, it's your fault, not society's. /s
palata commented on Australia begins enforcing world-first teen social media ban reuters.com/legal/litigat... · Posted by u/chirau
Of course they aren't. If they were actually helping kids, they would be going after algorithmic feeds in general and the most predatory platforms like Roblox (especially given its recent scandals), doing something about kids being exposed to gambling advertising, etc.
The bill was put up for public comment for less than one business day before being rammed through Parliament. Australia is just sending out one of the horsemen of the infocalypse so that other countries have an excuse to follow suit. Like how our "Assistance And Access" Act was a test run of the UK's "snooper's charter".
This law will just lead to:
1. kids pretending to be adults so they sneak through these filters
2. platforms winding back their (meagre) child safety efforts since "children are banned anyway"
3. everyone being forced to prove their age via e.g. uploading ID (which will inevitably get leaked)
> kids pretending to be adults so they sneak through these filters
The real question is: how hard does it make it for them to pretend to be adults? We just need it to be hard enough that most kids won't do it.
> platforms winding back their (meagre) child safety efforts since "children are banned anyway"
If the law forces the platforms to properly ban children, I don't see how they can do that. If you're thinking that the platforms will just say "it's illegal for children to join, so we don't have to do anything because they shouldn't come in the first place", then I don't think the law is made like this.
> everyone being forced to prove their age via e.g. uploading ID (which will inevitably get leaked)
Some countries have been working on privacy-preserving age verification. I find it's a lot better than uploading an ID.
Probably a bad habit trying to stop them, they need to learn walking before they can sprint. The question is always how to put limits on them? I say it's overengineered, they say it's modern code and I am old. So what do you do if they send you a PR that is just plain wrong? I mean it seems like you delay the conflict from upfront design/planning to pull requests.
* Functional teams (established companies): enough seniors are here to tell the juniors when they are wrong, and the juniors naturally accept the criticism because it's expected in that environment.
* Dysfunctional teams (startups): most devs are juniors anyway, there is no clear hierarchy, managers are still at their first job so they have never seen a functioning team or had a competent manager themselves.
In the second case, there was absolutely no way I could win an argument: the "high energy kids with big egos" never believed me, I was the "old guy" as you mention. I remember an example where the "kid" failed and gave up with their "right" way after 3 months and I solved it in 3 days, exactly how I had suggested they did it in the first place. Next discussion, nothing had changed, they still knew better.
I can't really blame them, because the whole environment was like this. Everybody was always right, knew better, etc, even though it was their first job.
What I've learned is to protect myself and move away from that. Either by changing job, or by changing project. In startups I have been pretty successful at saying "I can help with this project if we do it this way, but if we do it that way, I can't help and I will work on something else". Of course it meant that I could not work on the most exciting project, but they made a mess out of them, so all in all I feel it was better working on my boring, stable, maintainable components.