9

On C++ forum and see reference to Type Erasure (TE). Search around, some Java shit bleeding into other programming languages. Finally find an article that not only explains what TE is, but why you would use it in C++. ITS JUST FUCKING DUCK TYPING. Please stop using stupid names for stuff. You don't sound smarter. You sound like an asshole. Anyway, thinking about it does make sense to call it Type Erasure, but I still think it sounds pretentious. Cool concept, stupid name. Will continue to confuse people saying: "oh, you mean duck typing?"

Cool article:
https://davekilian.com/cpp-type-era...

The wikipedia article about TE doesn't explain shit about why you would even use it. Just repeats the same word salad of words I first saw about TE. I get that its jargon, but from the outside it just sounds like bullshit. I have never heard anyone I work with spew out shit like that. Even the ones with masters degrees in computer science.

I am not even sure I want to learn more about CS than what keeps me employed. I don't want to sound like this when I talk. I have already said shit in meetings about modern C++ that has colleagues (other sparkies, and some CS people) wondering what I was smoking. It wasn't even that jargony.

Don't mind me, just a sparky starting to understand why the CS world is so fucked. Maybe its just academia I can't stand. I dunno.

I should ask in a meeting if someone can define a monad for me.

Comments
  • 1
    Truth be told. Duck Typing is kinda stupid name too. But it is more fun, because ducks!
  • 2
    how I feel with rust

    weird names and nobody explains them (they keep saying type erasure also)

    and most of the users also don't know what they mean and yet the "community leaders" keep using them

    it's the dumbest shit

    I hate names to begin with. use an analogy and stop being a snob. do you care about people getting it or you sounding like you're part of some superior knowledge cult and others aren't good enough to be allowed into your super secret club?

    and the kicker is the rust book everyone says will teach you rust actually doesn't tie anything into low-level concepts which actually made reading the book totally useless in my opinion. it's like someone trying to teach a programming language to 4 year olds. try not to fall asleep. learn nothing. everybody will disagree with me tho, the book is considered some holy Bible. joke
  • 3
    @Demolishun duck typing is an analogy =]

    "walks like a duck, talks like a duck, it's basically a duck"
  • 1
    @jestdotty yes, I used duck typing a lot in Python. Other than the boiler plate it might be useful in C++. The analogy terms are more fun. Reminds me of the debate of electron flow vs hole flow in electronics. Trying describe magic or charge potential flow. We know what it does, but not exactly how it does it.
  • 1
    @jestdotty kicker is there's an earlier version of the rust book hosted at some MIT url and that one was written by a man and the introduction chapters actually delve into low-level established computer science concepts so I read that book instead

    I wish they kept with that but in the new book they ripped that out and went in another direction

    it's literally like they're trying to be hostile to the existing culture and knowledgebase in computer science 😒

    (the new rewrite was written by a woman for some reason, you can track git commits and she comes in out of nowhere -- and she does not write well it's literally confusing, inexact, vague. why the fuck would you switch to this author, DEI / rust foundation drama? only explanation)

    it's literally like they wanna destroy stuff
  • 1
    @jestdotty 1984 in the Rust community?
  • 2
    @jestdotty haha, I should describe programming terms with electronics concepts and math. Call arrays -> data capacitors. Database -> data capacitor bank. Describe everything in terms of data flow and define latency as propagation delay. I wonder of networking can be modeled as electrical networks?
  • 1
    @Demolishun there was an hour talk at some university about how analogies are the best means of transmitting information

    it's true. you wanna be a good teacher, tie new knowledge to old knowledge the person already intrinsically has. there's no "memorization" like @lensflare seems to believe in. it's like a memory palace of your childhood home but you can do this for concepts, so not a memory palace of your childhood home but everything from how to ride a bike, how to make a coffee, how someone takes a piss, etc. everything. no memorizing needed

    analogies are the same thing as extracting monad functions out of someone's head and reusing them somewhere else in their conceptual map! program a human today!
  • 1
    @Demolishun if you're teaching an electrician that would be a super fast way to speed them up
  • 2
    @Demolishun idk if it's bad enough to be 1984, certainly an awful lot of imprecision and confusion though

    but I do remember trying to care about their words and on their own forums everyone was arguing on old posts what the words mean

    but I could tell they had logical loopholes in their explanations so their definitions were also undoubtedly wrong lmao

    it's a disaster

    if it runs it works. that's where I'm gonna leave it at. hopefully the cancer will destroy itself and the community will be reborn anew at some point. there's certainly enough money flowing in to keep it propped up
  • 1
  • 1
    type erasure took me a while to understand too, but yeah at some point i realized it pretty much just duck typing
  • 0
    It's not duck typing, c++ templated types can get COMPLICATED so you wrap it in something akin to an interface.
  • 3
    Duck typing is not the same as type erasure.

    When you have a most generic type like "any" in TS, "id" in objective-c, "dynamic" in C#, or anything in a dynamically typed language, then you can call any function on a variable with that type, regardless if that function exists or not.
    If that function happens to exist, you can deduce at least some info about the type.
    So, if you call quack() and it exists, then you can assume that it‘s a Duck type.
    That’s duck typing.

    Type erasure is just the practice of casting a value of a specific type to a more generic type so that it‘s more convenient to work with it.
    For example if you have an array of Animal types and you want to store more specific types in it like Dog, Cat, Duck, then those objects become type erased when they are inside the array, because when you access them, they are all Animal.
  • 2
    You asked for monads, I watched a video recently which did a very good job to explain it, in my opinion.

    For reference, I watched many other videos about monads, including the one from Computerphile, but none of them did it for me.

    https://youtu.be/C2w45qRc3aU/...
  • 0
    @jestdotty Besides a focus on performance, Rust just likes to be different in syntax that other languages anyway on many points. The return type followed by the rest of the signature was too awesome. Unbeatable. It's just a bit harder to parse, how do you know if it's a function definition and not a variable? This is why simple regex fails, custom types. If you put it behind it with '->' you know that everything behind the '->' is the return type. Regexing that would even work with custom types. Hmm, so in sense of interpreting or syntax highlighting it's better. But i hate the "fun" prefix. It's not fun. If you assign a var, the IDE would show up with compatible types, not mattering if it's a fun or not. So fuck fun! C type prefix unbeatable. What good stuff did Rust learn from other languages?
  • 0
    What is your opinion about the 'auto' keyword? It can only be one think afaik It's kinda lazy and you need an IDE to resolve the type later. It's not that user friendly tbh. Bit lazy?
  • 2
    @retoor I like auto for variable declarations, less so for return types. For templated STL types it just saves typing and saves working out what the specific return type is. A good example is iterators, you (and everyone else) know the semantics of the return type, but the specific type doesn't give additional information. Also, thanks to templating, it might be grossly complicated to declare the actual type. Less noise.
  • 1
    @atheist so you have the same keyword for type inference on variable declarations and for opaque return types? That’s interesting.
    In Swift those are two different concepts which have different syntax.

    To illustrate why they are different:
    What type would the compiler infer for a function which has an if statement and returns A for the true case and B for the false case?
    This would be a compiler error in swift when the return type is defined to be opaque (which is sometimes referred to as inverse generics)
  • 0
    @Lensflare it's not type inference, it's type evaluation. C++ is a strictly typed language. If the type is ambiguous it's a compilation error. For a function to return one of two different types it can be switched between by a template argument, compile time evaluated parameter.
  • 2
    @Lensflare the closest thing to duck typing in c++ is template constraints and requirements. But it's all compile time evaluated.
  • 0
    @atheist

    > it's not type inference, it's type evaluation.

    I never heard about this distinction being made. What’s type evaluation and how is it different from type inference?
    When I google C++ type inference, it spits out "auto". Is this wrong?

    > C++ is a strictly typed language. If the type is ambiguous it's a compilation error.

    Yes, I made this example to explain why return types cannot have type inference. That’s why I was surprised to learn that they have the same keyword as type inference (auto) in C++.

    > For a function to return one of two different types it can be switched between by a template argument, compile time evaluated parameter.

    Yes but then you have normal generics.
    That’s why opaque types are referred to as reverse generics. They specify the type from the inside, the body of the function, rather than from the outside, by calling the function with a generic parameter.
  • 1
    @atheist

    > the closest thing to duck typing in c++ is template constraints and requirements. But it's all compile time evaluated.

    Maybe. I don’t think that C++ can have real duck typing. It lacks this "generic type" that the other languages which I mentioned have.
    It also lacks dynamic member lookup (I believe)
  • 0
    I guess my point with inference vs evaluation is inference can imply ambiguity depending on context, c++ it's not ambiguous
  • 1
    @Lensflare it can't have python's style of duck typing where you pass something to a function and if it doesn't have the right attributes/methods an exception is raised because that's evaluated at compile time. But templating and constraints/requirements IMO allow for better duck typing because the function signature tells you you should pass a duck instead of a car.
Add Comment