[dpweb]

I disagree I think we always need new languages. Every language over time becomes more and more unnecessarily complex.

It's just part of the software lifecycle. People think their job is to "write code" and that means everything becomes more and more features, more abstractions, more complex, more "five different ways to do one thing".

Many many examples, C++, Java esp circa 2000-2010 and on and on and on. There's no hope for older languages. We need simpler languages.

[embedding-shape]

> Every language over time becomes more and more unnecessarily complex.

Of course someone eventually will, so I might as well: Well, except for lisp-likes. I think the main reason programming languages grow and grow, is because people want to use them in "new" (sometimes new-new, sometimes existing) ways, and how you add new language features to a programming language? You change the core of the language in some way.

What if instead you made it really easy to change the core language from the language itself, when you need to, without impacting other parts of the codebase? Usually if you use a language from the lisp-"family" of languages, you'll be able to.

So instead of the programming language everyone is using grows regardless if you need it or not, it can stay simple and relatively small for everyone, while for the people who need it, they can grow their own hairballs "locally" (or be solid engineers and avoid hairballs in the first place, requires tenure/similar though).

[kwanbix]

Related to your comment. I was a "desktop" developer many years ago (about 20). Back then I mainly coded in Assembler, Visual Basic, and Delphi, and I also learned COBOL, C, and Java.

Just this week, I decided to start learning Kotlin because I want to build a mobile app.

Everything was going great until I reached lambda functions.

Honestly, I can't wrap my head around either their purpose or their syntax. I find them incredibly confusing. Right now, they feel like something that was invented purely to confuse developers.

I know this might just be one of those topics where you suddenly have an "aha" moment and everything clicks, but so far, that moment hasn't come.

Did anyone else coming from older, more imperative languages struggle this much with lambdas? Any tips or mental models that helped you finally "get" them?

[gridspy]

You know how to add logic on the outside of a function, by putting that function into a larger one and calling the function in the middle.

However, how do you inject logic INTO the middle of a function?

Say you have a function which can iterate over any list and given a condition do a filter. How do you inject the condition logic into that filter function?

In the C days you would use a function pointer for this. C++ introduced templating so you could do this regardless of type. Lambdas make the whole process more ergonomic, it's just declaring a one-shot function in place with some convenient syntax.

In rust instead of the full blown

fn filter_condition(val: ValType) -> bool { // logic }

I can declare a function in place with |val|{logic} - the lambda is just syntactic sugar to make your life easier.

[coloneltaint]

They're just functions that you define inside another "outer" function's local scope, and depending on the language they will/can also work as closures - meaning they capture the values of variable in the outer function as well.

I don't know the syntax of kotlin, but lambda functions generally are usually useful to pass as parameters to other, generic/higher-order functions. For example if you have a sort function `sort(listofitems, compareitems_fn)` you could write the `compareitems_fn` as a lambda directly in-line with the call to sort()