5 ms·

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 undoin

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.

alcasa 7mo ago
Maybe controversial, but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.
- rdevilla 7mo ago
  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.
  - red_admiral 7mo ago
    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/java/util/function/Consumer.html https://docs.oracle.com/en/java/javase/21/docs/api/java.base...
- delecti 7mo ago
  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.
  - ansgri 7mo ago
    I feel like half of junior programmers are susceptible to this.
  - jghn 7mo ago
    > 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
  - teddyh 7mo ago
    There is now a second edition of that book which has supposedly been rewritten to fix that.
  - oldestofsports 7mo ago
    It strongly pushes for max 3 LOC per function, and I am not even joking.
- joe_mamba 7mo ago
  > 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.
- t43562 7mo ago
  I think it's more the idea that if using a pattern is good then using all of them at once is even better.
- glitchc 7mo ago
  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.
  - kdfjgbdfkjgb 7mo ago
    I think they meant "OOP patterns". Not that I agree with them
  - array_key_first 7mo ago
    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.
- Aeolun 7mo ago
  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.
  - Scarblac 7mo ago
    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.
    - 9rx 7mo ago
      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.
    - Aeolun 7mo ago
      With dependency injection your interface always describes what your implementation can do. If you see the interface and you have to care what is going to happen when you use it you are doing it wrong.
  - layer8 7mo ago
    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.
    - oldestofsports 7mo ago
      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?
- antonymoose 7mo ago
  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.
  - domga 7mo ago
    A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions
    - irishcoffee 7mo ago
      Are you referring to function pointers? I believe C has allowed passing and returning functions from... the jump, no?
      - scott_w 7mo ago
        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."
      - ndriscoll 7mo ago
        Not just function pointers. E.g. in Scala: def addX(x: Int): Function[Int,Int] = { y => x+y } 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.
- hibikir 7mo ago
  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.
  - bluGill 7mo ago
    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.
- hsuduebc2 7mo ago
  I believe it's more like formal letter, or prefilled form where you only fill data when required. It actually can be useful.
- exceptione 7mo ago
  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.
- SoftTalker 7mo ago
  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.
  - PunchyHamster 7mo ago
    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"
  - mikkupikku 7mo ago
    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.
CGMthrowaway 7mo ago
>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
- duped 7mo ago
  > Which is not to be read as a necessarily "bad" thing I (and many others) read it as "dishonesty"
  - Barbing 7mo ago
    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.
    - arethuza 7mo ago
      "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.
      - VorpalWay 7mo ago
        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.
AreShoesFeet000 7mo ago
There are no natives anymore. For some time, really. Honestly I don’t even think there ever were.
lo_zamoyski 7mo ago
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.
- ryandv 7mo ago
  [dead]
raffael_de 7mo ago
> formal languages exist; as [...] a system for turning bullshit into parse errors that's a very neat way to put it!
jancsika 7mo ago
> 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.
utopiah 7mo ago
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.
AnimalMuppet 7mo ago
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.
- cyanydeez 7mo ago
  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.
PunchyHamster 7mo ago
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.
adampunk 7mo ago
You seem nice
leonardoe 7mo ago
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.

alcasa 7mo ago

Maybe controversial, but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.

rdevilla 7mo ago
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.
- red_admiral 7mo ago
  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/java/util/function/Consumer.html https://docs.oracle.com/en/java/javase/21/docs/api/java.base...
delecti 7mo ago
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.
- ansgri 7mo ago
  I feel like half of junior programmers are susceptible to this.
- jghn 7mo ago
  > 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
- teddyh 7mo ago
  There is now a second edition of that book which has supposedly been rewritten to fix that.
- oldestofsports 7mo ago
  It strongly pushes for max 3 LOC per function, and I am not even joking.
joe_mamba 7mo ago
> 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.
t43562 7mo ago
I think it's more the idea that if using a pattern is good then using all of them at once is even better.
glitchc 7mo ago
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.
- kdfjgbdfkjgb 7mo ago
  I think they meant "OOP patterns". Not that I agree with them
- array_key_first 7mo ago
  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.
Aeolun 7mo ago
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.
- Scarblac 7mo ago
  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.
  - 9rx 7mo ago
    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.
  - Aeolun 7mo ago
    With dependency injection your interface always describes what your implementation can do. If you see the interface and you have to care what is going to happen when you use it you are doing it wrong.
- layer8 7mo ago
  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.
  - oldestofsports 7mo ago
    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?
antonymoose 7mo ago
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.
- domga 7mo ago
  A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions
  - irishcoffee 7mo ago
    Are you referring to function pointers? I believe C has allowed passing and returning functions from... the jump, no?
    - scott_w 7mo ago
      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."
    - ndriscoll 7mo ago
      Not just function pointers. E.g. in Scala: def addX(x: Int): Function[Int,Int] = { y => x+y } 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.
hibikir 7mo ago
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.
- bluGill 7mo ago
  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.
hsuduebc2 7mo ago
I believe it's more like formal letter, or prefilled form where you only fill data when required. It actually can be useful.
exceptione 7mo ago
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.
SoftTalker 7mo ago
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.
- PunchyHamster 7mo ago
  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"
- mikkupikku 7mo ago
  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.

CGMthrowaway 7mo ago

>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

duped 7mo ago
> Which is not to be read as a necessarily "bad" thing I (and many others) read it as "dishonesty"
- Barbing 7mo ago
  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.
  - arethuza 7mo ago
    "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.
    - VorpalWay 7mo ago
      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.

AreShoesFeet000 7mo ago

There are no natives anymore. For some time, really. Honestly I don’t even think there ever were.

lo_zamoyski 7mo ago

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.

ryandv 7mo ago
[dead]

raffael_de 7mo ago

> formal languages exist; as [...] a system for turning bullshit into parse errors that's a very neat way to put it!

jancsika 7mo ago

> 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.

utopiah 7mo ago

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.

AnimalMuppet 7mo ago

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.

cyanydeez 7mo ago
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.

PunchyHamster 7mo ago

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.

adampunk 7mo ago

You seem nice

leonardoe 7mo ago

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.