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.
It is awfully unproductive way to do it but I'm sure HR approves.
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
A prime example of corporate speak that is, as you rightly said, 'only effective among the "clueless"'
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.
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/...
This is a trait of a psychopath. Not surprisingly, one finds a lot of them in the executive ranks.
It definitely takes a certain kind of person to be a good fit in that role
Sociopaths can code-switch instantly - I wonder how much of this is training, versus emulating others, versus a fundamental difference in brain operations...
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.
Edit: seems that searching for „Gervais principle“ turned up what was talked about…
I (and many others) read it as "dishonesty"
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.
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.
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.
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.
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.)
It's all dishonesty at the end of the day.
that's a very neat way to put it!
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.
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
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.
I believe C has allowed passing and returning functions from... the jump, no?
def addX(x: Int): Function[Int,Int] = {
y => x+y
}
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.
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.
OOP has no firm theoretical foundation, unlike FP which is rooted in the formalisms of mathematics.
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...
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.
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.
Hence the benefit to testing; allowing you to inject a deterministic implementation while under test.
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?
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"
I see you're familiar with Uncle Bob's handiwork
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.
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.
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.
Theres no high minded difference. Its just in/out group identification.
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.
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.