Is the CS field creating terms for the sake of creating terms?

Someone mentioned a "closure" in another post. I instinctively knew what they meant by that based upon the code I saw. I had heard the term thrown around before, but it had not yet connected in my mind. I wondered why I had not been exposed enough to care.

So I thought: What does C++ have as far as closures?

I found that C++ has lambdas. Those are definitions for function objects. They do not exist at runtime. But a closure does. The analog is you have classes. They are definitions and do not exist at runtime. But instances of classes do. So at runtime the instance is what you are working with. This is the same as lambdas vs closures in C++. The closure is the runtime counterpart. Why a separate term for what essentially is an instance? Is it because it captures data and code? As far as I know the closure is all data that gets passed around that calls a function. So it is essentially an instance of a lambda.

Another term: memoization. I have yet to see this added to any dictionary in online tools like a browser. Is the term so specific that nobody cares to add it? I mean these are tools programmers use all the time.

My guess is these terms originated a long time ago and I have just not been exposed to the contexts for these terms enough. It just seems like I feel like I have been in the field a long time. But a lot of terms seem alien to me. I also have never seen these terms used at work. Many of the devs I work with actively avoid CS specific terms to not confuse our electrical coworkers. My background started in electrical. So maybe I just didn't do enough CS in college.

  • 0
  • 1
    In c# those are called delegates and instances

    You create a function prototype as a data type and instantiate it around another method with the same prototype or assign a lambda or anonymous function to it.

    Why are they calling them closures?
  • 0
    @AvatarOfKaine the only thing I can think is that they enclose data and code. Like { } closes those into a package.
  • 1
    Closures / IIFE’s (terrible name) also include some scope, whereas an instance does not. Well, it can via pointers, which is all JS is doing, but it feels like more while working with them. Also, classes in JS are very different beasts, so they probably use a different term to avoid dev confusion thanks to their stupid decisions surrounding classes. Just conjecture, though.

    As for “memoization” not appearing in the dictionary… I have absolutely no idea. I believe “cruft” is present, despite also being a programming-only term. Seems odd that the former wouldn’t be.
  • 4
    Lambda is a term older than computers, and closures were a property of lambdas for as long, though I'm not sure whether Church ever used this term. In many OO languages, lambdas and closures are actually imitated using classes and instances because the language already provides the necessary optimizations for these.

    Though these terms overlap, their equivalence is dependent on the specifics of the abstraction. Depending on the language, there may be things that are definitely closures and not classes, and things that are definitely classes and not closures.
  • 5
    closure has some mathematical meaning that these anonymous scopes or functions provide so that is okay in my book.

    "memoization" ticks me off, it's just a local cache FFS. There even exists a similar word for it: memorization.
Add Comment