[boomlinde]

> Explore languages that follow different paradigms, where interfaces just don't apply.

Interfaces as a general concept applies whether there is a type system to ensure that they are satisfied or not. Do you have function parameter lists? Do you have expected shapes for function inputs and outputs? Do you have distinct types? Then you have interfaces. Your shit breaks when they aren't conformed to. It has nothing to do with strong typing or object orientation. Strong, static typing is just a way to ensure at compile-time that the expected interfaces are satisfied.

> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.

[orange8]

> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

>>Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.

It wasn't me. Maybe a TypeScript compiler will help you correctly follow the comment threads? ;)

[orange8]

>> Then you have interfaces.

Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces. What you're talking about are patterns and best practices, so you're getting there...

JS is a dynamic language. Just deal with it already... you sound smart enough to support both paradigms at the same time in your head.

[boomlinde]

> Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces.

It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it.

> What you're talking about are patterns and best practices, so you're getting there...

Nope, what I'm talking about is interfaces. The nature of function signatures as interface points is not a matter of patterns and best practices. They simply are exactly that, whether it's spelled out for you or not.

> JS is a dynamic language. Just deal with it already... you sound smart enough to support both paradigms at the same time in your head.

This doesn't constitute an argument or an objection to anything I've said. It presumes that I won't "deal with it" when there is no evidence that I'm not. It supposes that "support[ing] both paradigms at the same time", whatever that means, is a matter of my intelligence. It doesn't argue for any of this.

[orange8]

> It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it.

Really? So now this has devolved into a debate about semantics? I thought this was about JS and TS, not the "general meaning of interfaces". Using that way of thinking, even HTML and CSS have interfaces. Arguing over semantics is a very common tactic by the way, if you just want to win a debate for arguments sake. Let us keep it specific. My point is JS, as a functional language does not have or even require many of the features and constructs of a strongly typed OOP language, interfaces being a good example. The inverse also applies.

Different programming paradigms = different patterns and best practices

>>Nope, what I'm talking about is interfaces. The nature of function signatures as interface points is not a matter of patterns and best practices. They simply are exactly that, whether it's spelled out for you or not.

Are you saying an interface is a function signature and is this what you mean by interfaces in general?

>>This doesn't constitute an argument or an objection to anything I've said. It presumes that I won't "deal with it" when there is no evidence that I'm not. It supposes that "support[ing] both paradigms at the same time", whatever that means, is a matter of my intelligence. It doesn't argue for any of this.

My responses do not have to be blow by blow objections to every single point you make. This is a discussion, not a computer program. And I stand by the sentiment: for optimal results, think functional when working in a functional language.

[boomlinde]

> Really? So now this has devolved into a debate about semantics?

You just reasoned on the basis of your "definition of a language feature" that I am wrong. Don't blame me for turning it into a discussion about semantics.

> I thought this was about JS and TS, not the "general meaning of interfaces". Using that way of thinking, even HTML and CSS have interfaces.

It is about JS and TS. A poster asked, about JS developers, "Do they just magically decipher what interface an argument conforms to?". There is a reasonable answer to that, and it isn't "This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply", which doesn't answer his question and instead assumes that the poster simply hasn't explored languages that for some unargued reason will change his question.

Obviously he is not talking about interfaces as a language feature, since he acknowledges that JS doesn't have explicitly defined interfaces.

You yourself have been talking about library APIs. I'm sure you know what the I stands for.

> Are you saying an interface is a function signature and is this what you mean by interfaces in general?

I am saying that they are interfaces. I am not saying that function signatures constitute the entirety of interfaces in general, and I'm not sure what I wrote that makes you even ask that question.

> My responses do not have to be blow by blow objections to every single point you make. This is a discussion, not a computer program.

It's a discussion, and I participate to discuss things, not to hear you tell me to "deal with it". But sure, I can't stop you from participating on whatever basis you prefer. I just want to point out that I get absolutely nothing out of it, so if you're writing that for my sake you can stop.

> And I stand by the sentiment: for optimal results, think functional when working in a functional language.

This is not about functional vs. non-functional. It's about JS and TS, as you've pointed out yourself.