I suspect this is why formal languages exist; as a sieve to keep the hordes of fools at bay, and a system for turning bullshit into parse errors.
We are undoing much of this progress by now insisting everything be expressed in natural language for a machine to translate on our behalf, like a tour guide.
The natives will continue to speak amongst themselves in their mother tongue.
This observation really resonates with me. I have spent a lot of energy trying to communicate that ditching formal languages for natural language is a terrible idea in some (most?) domains. The power of formal languages comes precisely from their "limitations".
Software is not the output. The output is the theory-building process by which one arrives a formal description of both the problem and (hopefully) the solution. Avoiding the effort to express a problem (or a model of the problem) in a formal language is a self-defeating enterprise.
The corpo-speak sounds like mostly way to communicate contentious things in nice way, everything done to not sound negative or aggresive, while knowing (or hoping) that other side gets the message.
It is awfully unproductive way to do it but I'm sure HR approves.
Which is precisely why proper scammers, not to say "top" management, is excellent at spotting keywords, or even better shibboleh, and using them. If they must they'll even learn and adopt new keywords from HBR or whatever trendy management publication can help them look the par.
>a sieve to keep the hordes of fools at bay
Corporate speak as a signalling mechanism is only effective among the "clueless" in the Gervais model. If any CEO tried to talk 1:1 to a competent board member that way, they would lose all credibility. Once you've operated at a certain level you get it
>a system for turning bullshit into parse errors.
This is the (cynical version of) the framing I tend to hold about corporate speak. It's deliberately vague as a way to navigate uncertainty while still projecting authority and avoiding accountability in settings like a town hall, large meeting etc. Which is not to be read as a necessarily "bad" thing. No one wants a micromanaging CEO. They have to set vision and direction while leaving space for it top be executed by all the layers under them
> They have to set vision and direction
A prime example of corporate speak that is, as you rightly said, 'only effective among the "clueless"'
No. It means things
Corporate speak as a signalling mechanism is only effective among the "clueless" in the Gervais model. If any CEO tried to talk 1:1 to a competent board member that way, they would lose all credibility. Once you've operated at a certain level you get it
This also holds true for competent non-board members. I have interacted with C-level executives at fortune 100 companies, as well as smaller businesses. It is almost impressive how quickly they can switch in and out of corporate bullshit mode. I think it's what the kids call code-switching.
In general, once they trust you a bit, and they know someone isn't listening they talk like a normal person. Then you ask a difficult question about the business and the corporate-speak kicks in like a security sub routine trying to prevent them from saying the wrong thing.
I have also met some that seemingly calculate their tone and cadence to try to manipulate the person(s)/people(s) they're talking to. It's fascinating when you catch them doing it, and it's different than simply matching like a chameleon. For example, they may use an authoritative tone with younger people, a kind but subtly threatening tone with anxious people, and a buddybuddy tone with a plumber or someone they know isn't going to put up with any bullshit.
I'm really curious how much of it is formally taught in MBA programs and stuff, how much is them copying each other, and if any of it is just a natural defense mechanism to the pressures of being in power.
Ultimately I think all of what you describe there falls into a bucket of personality traits and social skills that contribute to success in many areas of life.
It's some combination of what they call "self monitoring" in social psychology, plus general EQ and Machiavellian personality traits that allow people to read the room and adjust their tone, speaking style, word choice (including picking up in-group lingo quickly), posture etc to be most effective given the setting. This applies to basically any social environment, and is often a frustrating reality to many people who may be extremely competent but see others around them who are obviously less competent "getting ahead" through social acumen, office politics etc.
This has been studied among MBA graduates, Do Chameleons Get Ahead, The Effects of Self-Monitoring on Managerial Careers (pdf): https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/...
what you view as subtly manipulative is just having good social skills
> I have also met some that seemingly calculate their tone and cadence to try to manipulate the person(s)/people(s) they're talking to.
This is a trait of a psychopath. Not surprisingly, one finds a lot of them in the executive ranks.
The polite term these days is "sociopath", which takes out the whole "psycho-killer" weightedness (because a sociopath can be very likeable and friendly) - and they fill the ranks of leadership in all professions...
The higher up you are in a company the more of “yourself” you have to give as realistically many more people are relying on your job results than they are on your personal wellbeing.
It definitely takes a certain kind of person to be a good fit in that role
Haven't there also been many studies that show high-level executives also have a high number of "sociopaths" in their ranks?
Sociopaths can code-switch instantly - I wonder how much of this is training, versus emulating others, versus a fundamental difference in brain operations...
The Gervais model! I haven't heard that in a while.
The Gervais model is predicated on sociopathy as the driving force of social cohesion. This is the kind of model a sociopath would construct. There are other models available to us.
Social organizations require some sort of glue to bind them together. They need ways to maintain cohesion despite vagueness and to obscure (small) errors. There is a cap put upon max individual output, but aggregate output is much higher than whatever a collection of individuals could attain. This is a very basic dynamic that is lost amidst a cult of individualism that refuses to admit to any good greater than themselves.
Yes - the CEO talking to the board in this way would lose credibility. But a CEO failing to deploy this jargon correctly would also lose credibility with the board : it's obvious he doesn't know how to lead.
What I would like to see is a study of the ratio's between corporate speak and technical speak - and the inflection points at which too much of either causes organization ruin.
Hate to ask, but since it came up again and a quick search couldn’t find it - what’s that Gervais model? Links / explanations welcome!
Edit: seems that searching for „Gervais principle“ turned up what was talked about…
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-... is a good explanation. The diagram of the "MacLeod Cycle" utterly convinced me, having been around that loop a few times.
> Which is not to be read as a necessarily "bad" thing
I (and many others) read it as "dishonesty"
Is there a historical example or does anyone have an anecdote of some crunch time where the CEO blowing hot air was the best thing for morale? Compared to what I might think a lot of us would prefer in many cases, which might be an honest assessment & making us part of the journey to overcome whatever adversity.
"an honest assessment & making us part of the journey to overcome whatever adversity"
I suspect that most people just aren't wired up that way - we have a natural tendency to want to follow leaders and what we seem to want most from leaders is certainty and confidence. Does it matter what leaders are certain and confident about - not really.
It is hard to argue with a vague statement like "most people" without a proper scientific study. But I disagree: following the scientific principle, and being willing to change opinion in the face of new evidence increases my trust in someone. Someone who is certain and confident without showing their work / sources make me suspicious. And critical thinking is (pardon the pun) a critical skill.
If you actually think and act that way, so much the better. I don't even particularly disbelieve you. But can you really look at the mass of humanity around you and believe they think the same way? Even if they claim to value critical thinking, watch what they do, what they buy, how they vote.
You've most likely trained yourself to value critical thinking in your leaders, most likely from an early enough age that you don't remember what it was like without it. Lots of people don't get this training or don't apply it in a fully general way.
Hm, having a journalist and an academic (with a heavy focus on applied rigorous statistics) as parents probably helped there, you are right. But school is supposed to teach this, at least here in Sweden it is a part of the curriculum. But indeed, that doesn't seem to help, and the US it is especially bad (not saying the situation is good here either though).
There are other things I do remember having to train myself to do though, such as not make value judgments based on the language skill level of others. Rationally I have never cared where someone is from and if they are a native speaker or not, but emotionally that required some effort.
I'm not convinced it's actually possible to teach critical thinking to someone who doesn't care, but I'm glad your schools are trying harder.
But even when people are trained in critical thinking, the part at the end of my comment about applying it in full generality is also critical. You have to be emotionally ready to apply it in cases where it produces unpleasant conclusions, not just for your job or when it helps dunk on your political opponents. Also difficult to impossible to teach at scale.
Not exactly?
Let's say there are a thousand people there at the town hall. You don't want any of them to leave upset, or even concerned. But they each have different things that will make them concerned and upset. So there are maybe 10,000 tripwires out there, and you don't want to trip any of them.
So you're not being dishonest, exactly. You're being nonspecific. You don't want to get down in the weeds and nail down the answer too tightly, because you may trip someone's tripwire. (And also because it would take to long.) So you say something true but not very specific.
(I mean, there can be dishonesty, too, but that's a different thing. Smooth vagueness can still be honest, just unsatisfyingly vague.)
"Smooth vagueness" to me comes off as tautologies. If you cannot say anything specific it means either you don't know, or don't want others to know. So it is a lie about ones' competency, or a lie by omission.
It's all dishonesty at the end of the day.
> formal languages exist; as [...] a system for turning bullshit into parse errors
that's a very neat way to put it!
Maybe controversial, but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.
Wildly controversial!
I look at OOP Patterns as standards and practices.
The same way we have building codes for staircases the framing of walls and electrical installations to prevent injury or collapse or fire.
Sure, you can dodge a lot of design pattern paradigms and still make a working application that makes money. You can also invent your own system when building your house and maybe nothing bad will happen. That tragedy hasn’t yet struck does not make the building codes bad just because you got away with it.
A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions
It's both.
The *concept* of patterns makes sense. A shared language that developers can use when building things.
The *reality* of patterns has been much less useful. The original ones were indeed a reaction to warts in the popular languages of their era. And as we tend to do in our industry, these have been cargo culted along the way and for some reason I still see people talking about them as first class citizens 30 years later.
People don't seem to realize that patterns should be and are fluid, and as our industry evolves these patterns are evolving as well. A major difference between software engineering and the analogous fields people use when talking about patterns is those industries are much older and move less quickly
A pattern is exactly what the word "pattern" implies; something that lots of people seem to have found useful, so you might find it useful too.
If you are a language designer and you see lots of people writing the same boilerplate, it behooves you to put it into the language. A pattern is a desire path - pave it. In that sense, they are missing language features.
Since a single-method object easily serves the role of such a function, that’s simply not true. Looking at the 23 GoF patterns, I can’t identify any that would be obviated by having first-class functions (or lambdas, as many OO languages nowadays have). Some of the patterns can employ first-class functions (e.g. an observer could be just a callback function reference), but the pattern as such remains.
The language feature isn't "passing and returning functions" but "loose coupling." Lambdas and Functors are just a way to represent that in OOP languages that care more about inheritance than about messaging.
A lot of patterns have become frameworks, or language features, yes. It's just paving cowpaths.
Are you referring to function pointers?
I believe C has allowed passing and returning functions from... the jump, no?
I recall a lot of this comes from Java 5/6 where I think passing function pointers around was difficult, if not impossible. Back in those days, I had many a conversation with a friend who would ask "can Python do pattern/feature X?" to which I'd respond "it doesn't need to."
Not just function pointers. E.g. in Scala:
addX(5) then returns a function that adds 5. So closures, which are equivalent to objects (behind the scenes, the compiler needs to allocate a structure to remember that 5 and know the "member function" to call to do the plus), and usually more straightforward.Once you get used to doing this, you realize it's useful everywhere.
In a decent language with functional programming and generics support a lot of GoF patterns can be directly encoded as a simple type signature where you receive, return, or both some function, so there's not really much else to say about them. Like half of the behavioral patterns become variations of the interpreter pattern.
Pardon my ignorance, isn't that a lambda in c++?
Yes, and in Java and other languages (e.g. in Lean you can literally use the syntax λ x ↦ x + 5). When OOP was more of the zeitgeist, these languages didn't have lambda functions.
You can return function pointers but not first class functions, which means you can’t do closures and other FP things in C
Design Patterns is more like the Human Factors and Ergonomics Handbook.
You can have your building engineered, in which case building walls out of 2x6's 16 inches on center is not off the table, but neither is a mortise and tenon timber frame with partition walls. In that paradigm, the code tries not to be descriptive of an exact technique but only gives you criteria to satisfy. For example you could run all of your electrical wiring on the outside of the walls or on the outside of the building, and you could use ramps instead of staircases. It only talks about ingress and egress for fire safety, and it explains how you're supposed to encase wires, or if wires are not encased it describes the way the wiring must be sheathed to protect the occupants.
You can heat your house entirely with an open fire, and the code speaks to how to do that safely. So it's unlike "design patterns" in a lot of ways in that the code tries to accommodate the kinds of buildings we try to build and the ways in which we modify buildings because that's easier than saying "these are all the allowed ways of building an entry staircase." Design Patterns are more in the latter category.
I disagree with that take. Design patterns are a language for (= give standard names to) patterns that tend to repeatedly occur in code, so that we can efficiently communicate about them. Programmers working in the respective contexts tend to reinvent them sooner or later if they don’t know them already, so it makes sense to circulate the knowledge about them. But that doesn’t mean that they are prescriptive.
You aren't wrong. The problem with this is the overuse of it. Its the main thing people criticize Java for. Even though it doesn't have anything to do with Java language but instead has to do with Java the business ecosystem or culture. When these are overused, that's when it becomes an in-group/out-group jargon thing.
OOP pattern were useful for people stuck in a pure OOP language (say Java 1.4) And needed to make something understandable. Today, when many languages, including Java, have reasonable functional programming support, a large percentage of the patterns are over complicated. Just look at the list, and see how many can be replaced with less boilerplate by passing a function, doing some currying, or both.
That doesn't replace the pattern, it just does the pattern by a different name. Design Patterns was never about OOP - the publisher added OO to the title because that was the fad at the time, but the patterns happen in other systems as well, they are just implemented differently.
I agree. Mostly they are copes for lack of first-class functions and multiple dispatch. Go through GoF and you will see this is the case for 80% of the patterns.
OOP has no firm theoretical foundation, unlike FP which is rooted in the formalisms of mathematics.
Ok, I'm in an argumentative mood, and I think this is more true than not.
The first theoretical foundation of OOP is structural induction. If you design a class such that (1) the constructor enforces an invariant and (2) every public method maintains that invariant, then by induction it holds all the time. The access modifiers on methods help formalise and enforce that. You can do something similar in a functional language, or even in C if you're disciplined (especially with pointers), but it was an explicit design goal of the C++/Java/C# strand of OOP to anchor that in the language.
The second theoretical foundation is subtyping or Liskov substitution, a bit of simple category theory - which gets you things like contravariance on return types and various calculi depending on how your generics work. Unfortunately the C++ people decided to implement the idea with subclassing which turned out to be a mess, whereas interface subtyping gets you what you probably wanted in the first place, and still gives you formalisms like Array[T] <= Iterable[S] for any S >= T (or even X[T] <= Y[S] for S >= T and X[_] <= Y[_] if you define subtyping on functors). In Java nowadays you have a Consumer<T> that acts as a (side-effectful) function (T => void) but composes with a Consumer<? super T> to get the type system right [1].
Whether most Java/OOP programmers realise the second point is another question.
[1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base...
Why is OOP lumped with Clean Code? Objects are useful for managing complex states and relationships. They are complementary, not mutually exclusive, to procedural and functional programming.
Usually when people refer to OOP they don't mean encapsulation, although that's the core tenant of OOP. Encapsulation, private and public etc is a given. Usually they're talking about the other OOP stuff, like inheritance. Inheritance is pretty much bad and is the wrong abstraction for 90% of stuff.
I think they meant "OOP patterns". Not that I agree with them
When applied without thinking about why. Yes.
Except dependency injection. I really can’t imagine why you’d ever not use that. I suppose it’s possible to overuse, but you’d still have better code than without. Certainly more testable code.
Because code becomes harder to understand.
With direct dependencies, if you are trying to understand some code that calls some function and what it does exactly isn't completely obvious, you can press a button to go to it, understand it, and come back.
With dependency injection it depends on what is going to be inserted during runtime, so you can't.
If you can press a button to understand what is going on, "it’s possible to overuse" most definitely applies. Dependency injection, as the name implies, is for dealing with dependencies — things that you cannot observe until runtime.
Hence the benefit to testing; allowing you to inject a deterministic implementation while under test.
Unless you mean just regular constructor parameters, dependency injection in the sense of a runtime dependency injection framework is the one thing I try to avoid like the plague.
That is called a "DI Container", and usually manages the objects and order of instantiation etc.
Dependency injection simply means to take objects as parameters, and not instantiate them themselves (which causes "Inversion of Control" also commonly mentioned when talking about DI). DI Containers just makes the managing of objects easier.
Avoiding it like a plague seems excessive, did you have a bad experience with them?
When Martin Fowler coined the term Dependency Injection [0], that was specifically for the context of container instrumentation. Merely passing service objects as constructor parameters is more akin to the Strategy pattern. At least in the Java world where it originated, “dependency injection” has always been about wiring application components and services together at runtime based on configuration, often directly injecting the dependencies into object fields via reflection, and not about statically compiled constructor invocations that happen to pass service objects.
[0] https://martinfowler.com/articles/injection.html
Most of OOP and design patterns was yet another attempt to make it possible for lower-ability (i.e. cheaper) developers to be productive. Just like dimensional lumber and standards like "wall studs are spaced 16 inches on center" made it possible for a lower-ability carpenter to frame a house and have everything fit together properly. Though in the latter case, it actually was successful.
Nah, the engineering standards like that generally make everyone's job easier; the "pro" carpenter will save just as much time as the newbie, hell maybe more.
Design patents are more of "you need to build house with this exact room layout" than "the materials and ways to put them together are standarized"
There's a strong element of that, but there's more to it. It is to the advantage of management that even their experienced developers all speak the same design language, if only because this makes any individual developer easier to replace. Corps don't want a situation where the whole company is hanging off one brilliant programmer's completely impenetrable code. TempleOS is awesome, but not for businesses.
I worked with a junior dev who suddenly got really excited about Clean Code. Every example he brought up left me feeling that there was a kernel of good advice, but the book wanted you to take it to such an extreme that it would result in shitty code.
> there was a kernel of good advice, but the book wanted you to take it to such an extreme that it would result in shitty code
I see you're familiar with Uncle Bob's handiwork
I feel like half of junior programmers are susceptible to this.
There is now a second edition of that book which has supposedly been rewritten to fix that.
It strongly pushes for max 3 LOC per function, and I am not even joking.
I think you can safely omit 'maybe'. OOP is harder and requires more design experience to achieve good results than functional programming. I welcome you to look at OOP code from people who don't get the patterns.
OOP can be wonderful, but the people who aren't able to step up a level in conceptual abstraction should really not touch it. Remember, for many years languages like Java didn't have any concept of lambda's and higher order functions, so design patterns were essential for elegant solutions. As they say, a design pattern is a symptom of the language being not expressive enough. In other words, many design patterns in OOP languages express the same thing as first-class language features in the functional paradigm would do, Visitor vs fold for instance.
I think it's more the idea that if using a pattern is good then using all of them at once is even better.
I believe it's more like formal letter, or prefilled form where you only fill data when required. It actually can be useful.
> but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.
They're the corporate equivalent of USSR soviet style conformism, when everyone had to call each other comrade and refusal to do that had repercussions.
Similarly, if you say you refuse to follow the Agile/Scrum manifesto or clean code practices, you get ousted, as that's Haram/not-Kosher in this racket.
I still wonder how Valve manage to ship Half Life without Agile or clean code practices.
But if someone says something like "synergizing paradigms", isn't that essentially a parse error to any normal person?
You don't need formal language (though formal languages can serve that purpose). You just need to listen like a normal human being rather than like a corporate suit, and that kind of language is just incomprehensible - a parse error. You have to work at it to make sense of that kind of language. And why I took from your first paragraph is permission to treat it as a parse error instead of as some valid message that I needed to decode.
My guy: corporate sloganeering is as much cultural appropiation as ghetto speak and drug culture.
Theres no high minded difference. Its just in/out group identification.
> a system for turning bullshit into parse errors
Because when I go to view an old website from the 90s that's missing a closing tag for something, I don't want the content-- I want a big red XML parse error with a gigantic horizontal scrollbar.
The history of programmers blithely attempting to add new parsing errors to existing problems instead of obviating them is long and storied. Your sentence would look right at home as part of the BS generated for the test subjects from the article.
That's not quite accurate. Formal languages (which have an old pedigree) can be useful for clarification and inference, but they can also obfuscate the truth, and what's more, subvert it. Every logical formalism necessarily presupposes some metaphysics, and if the metaphysics is bad, or you fail to recognize the effective bounds of that formalism, you can fall into mechanically generated bullshit. Modern predicate logic suffers from known paradoxes and permits nonsensical and vacuous inferences (like those caused by material implication). More subtle effects are expressed in, for example, the problem of bare particulars.
Formalism is a product of prior (semantic) reasoning that isn't formal. And because formalism is syntactic, not only can you still jam your semantic nonsense through it (through incoherent subjects and predicates, for example), but the formalism, stripped of semantics, can itself allow for nonsense. So formalism can actually aid and abet bad reasoning. The danger, of course, is the mistaken notion that "formal = rigorous".
Formalism is also highly impractical and tedious in many circumstances, and it can depart from human reasoning as expressed in the grammar of natural language enough to be practically inscrutable. There is no reason why natural language cannot be clear and well-written. So, I'm afraid you're barking up the wrong tree here.
The problem with LLMs isn't that they're not "formal". It's because they're statistical machines, not reasoning machines, yet many people treat them like magical oracles.
[dead]
You seem nice
There are no natives anymore. For some time, really. Honestly I don’t even think there ever were.