Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interfaces – The Most Important Software Engineering Concept

blog.robertelder.org

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Interfaces – The Most Important Software Engineering Concept

#31

Post by astral303 »

Polymorphism is very powerful, because it lets old code call new code.

But abstraction layers have costs. (Explicitly declared) interfaces are a cost (time to introduce into the system, complexity, lines of code, impedes refactoring).

Therefore, don't use interfaces (i.e. introduce abstraction layers) until needed (cost is justified).

By the way, if you manage to come up with a layer of abstraction that doesn't have as much explicit cost, it's a cheaper layer of abstraction. So dynamic languages' "duck typing" feature allows interfaces to emerge gradually, without explicit code to introduce them. Arguably, but IMO, that's a better approach.

I disagree with the article's definition of a leaky interface: "A Leaky interface exists when the interface is prone to being ignored during any communication between the system and the environment."

A leaky interface is an interface that has non-obvious, non-declared behaviors, and the code has to rely on those behaviors to deliver value/functionality.

It can be something as simple as an inconsistent implementation that leaks an underlying implementation detail. It doesn't mean that the interface is prone to be ignored. In fact, it can be used quite a lot--just in slightly different ways.

Re: Interfaces – The Most Important Software Engineering Concept

#32

Post by jstimpfle »

mbrock wrote: post #30
jstimpfle wrote: post #28

Earlier quoted context omitted.

> Low coupling means that the innards of each module are isolated from the others. Isn't coupling just the complexity of the dependency graph? I would say depending on an interface is coupling as well. In my experience complex static typesystems encourage highly abstracted interfaces which are sometimes even more cancerous dependencies (that doesn't apply for really basic and practical things like Iterables which com…

Maybe my understanding is idiosyncratic, but I see low coupling as most essentially meaning that the modules interact at small and well-defined boundaries, which gives you flexibility when you want to do things with the units like test them, replace them, etc. Depending on an interface can be a kind of coupling, sure, but I think it depends. I think abstract interfaces, or at least statically typed data types, can be…

Thanks. I think I confused low coupling with loose coupling.

Where do I find information about the Haskell module thing?

Re: Interfaces – The Most Important Software Engineering Concept

#33

Post by mbrock »

jstimpfle wrote: post #32
mbrock wrote: post #30

Earlier quoted context omitted.

Maybe my understanding is idiosyncratic, but I see low coupling as most essentially meaning that the modules interact at small and well-defined boundaries, which gives you flexibility when you want to do things with the units like test them, replace them, etc. Depending on an interface can be a kind of coupling, sure, but I think it depends. I think abstract interfaces, or at least statically typed data types, can be…

Thanks. I think I confused low coupling with loose coupling. Where do I find information about the Haskell module thing?

I'm not totally clear about the concept either. :)

It's called Backpack.

Re: Interfaces – The Most Important Software Engineering Concept

#34

Post by chii »

When i think of interfaces, i recall being told to think about how and why a DVD works.

The DVD would have been manufactured by a factory somewhere in china, by a bunch of people who does not know you. And yet, the DVD fits perfectly, on a drive that you bought, probably manufactured in the United States, by people who does not know you, nor the DVD manufacturer.

The software to read the DVD is written by yet another set of people, in yet another country, all of whom would not have talked to any parties mentioned above. And yet, the DVD is read perfectly, with error correction to adjust for any minor scratches.

The DVD plays video and audio data, created by people (probably in hollywood) who also have not met any of the parties above. And yet, it reproduces the sound and audio completely correctly as the original directors/composers intended.

And all of this, costs less than 50c a piece, with a drive that could be bought for less than $30.

That is the power of interfaces.

Re: Interfaces – The Most Important Software Engineering Concept

#35

Post by ced »

jb55 wrote: post #24
js8 wrote: post #17

I have been skeptical of the notion of "interface" lately. First of all, there is comment from Erik Meijer who said something like "interface without laws is useless" (he was referring to "interface" as a concept in OOP languages, and by "laws" he meant some algebraic laws). Basically what he wanted to know was the algebra, not just interface. And if you look at it from Curry-Howard correspondence perspective, where…

Indeed, this quickly becomes obvious after writing Haskell for awhile. Lawless typeclasses just seem clunky and get less reuse compared to their lawyer'd up brethren. You also can get a very slight taste of this in C#, Java, etc as well where larger interfaces seem clunky and get less reuse than smaller interfaces. In C#, if an interface has some nice properties, typically the extension methods on these interfaces wi…

Could you please give an example for someone not up-to-date on Haskell?

Re: Interfaces – The Most Important Software Engineering Concept

#36

Post by bunderbunder »

jb55 wrote: post #24
js8 wrote: post #17

I have been skeptical of the notion of "interface" lately. First of all, there is comment from Erik Meijer who said something like "interface without laws is useless" (he was referring to "interface" as a concept in OOP languages, and by "laws" he meant some algebraic laws). Basically what he wanted to know was the algebra, not just interface. And if you look at it from Curry-Howard correspondence perspective, where…

Indeed, this quickly becomes obvious after writing Haskell for awhile. Lawless typeclasses just seem clunky and get less reuse compared to their lawyer'd up brethren. You also can get a very slight taste of this in C#, Java, etc as well where larger interfaces seem clunky and get less reuse than smaller interfaces. In C#, if an interface has some nice properties, typically the extension methods on these interfaces wi…

One thing that baffles me a little bit about LINQ in .NET is that it's got a dual identity.

On one hand you've got the IEnumerable interface, which supports the fluent syntax and is extremely easy to riff on with extension methods. (The "fluent syntax" itself is just a bunch of extension methods.)

On the other hand you've got the mechanisms you need to support the query syntax, which behave more like duck typing. If you implement a couple methods with certain names and signatures, not all of which are formalized by an interface, then the compiler will let you use query syntax with objects of that type. It also turns out that the stuff you need to implement are roughly the bind and return operations from a monad. . . but not exactly. In particular, the element they use in place of bind is a bit more complicated, and not in a way that adds any real expressive power. It just makes the signature a bit more irritating to support.

In other news, re: lack of higher kinded polymorphism - That's something that the maintainers of F# have forcefully resisted adding to the language. The argument, which I've yet to take the time to look into deeply, is that typeclasses interact poorly with formal interfaces so you shouldn't allow a language to have both. I'm a bit skepty on that one, though, since I'd assume there would be wailing coming from the Scala community if it were really that bad.

Re: Interfaces – The Most Important Software Engineering Concept

#38

Post by platz »

bunderbunder wrote: post #36
jb55 wrote: post #24

Earlier quoted context omitted.

Indeed, this quickly becomes obvious after writing Haskell for awhile. Lawless typeclasses just seem clunky and get less reuse compared to their lawyer'd up brethren. You also can get a very slight taste of this in C#, Java, etc as well where larger interfaces seem clunky and get less reuse than smaller interfaces. In C#, if an interface has some nice properties, typically the extension methods on these interfaces wi…

One thing that baffles me a little bit about LINQ in .NET is that it's got a dual identity. On one hand you've got the IEnumerable interface, which supports the fluent syntax and is extremely easy to riff on with extension methods. (The "fluent syntax" itself is just a bunch of extension methods.) On the other hand you've got the mechanisms you need to support the query syntax, which behave more like duck typing. If…

Im guessing F# also may want to limit constructs which cannot interop with C# . Not sure if Scala's HKTs are usable from Java

Re: Interfaces – The Most Important Software Engineering Concept

#39

Post by eli_gottlieb »

js8 wrote: post #17

I have been skeptical of the notion of "interface" lately. First of all, there is comment from Erik Meijer who said something like "interface without laws is useless" (he was referring to "interface" as a concept in OOP languages, and by "laws" he meant some algebraic laws). Basically what he wanted to know was the algebra, not just interface. And if you look at it from Curry-Howard correspondence perspective, where…

Abstract types have existential type. ML/Coq modules are just existentially-typed "package" data. Haskell type-classes are just another variation on the same concept, with only one instantiation of the type-class allowed at each internal type so the compiler can search for instances coherently.

http://dl.acm.org/citation.cfm?id=45065&dl=ACM&coll=DL&CFID=...

Which reminds me, I should finish reading Tomer Ullman's PhD thesis to see if he managed to integrate existential types into his theory of causal-role concepts and theory formation.

Re: Interfaces – The Most Important Software Engineering Concept

#40

Post by vmorgulis »

chii wrote: post #34

When i think of interfaces, i recall being told to think about how and why a DVD works. The DVD would have been manufactured by a factory somewhere in china, by a bunch of people who does not know you. And yet, the DVD fits perfectly, on a drive that you bought, probably manufactured in the United States, by people who does not know you, nor the DVD manufacturer. The software to read the DVD is written by yet another…

Power of capitalism too.
Post reply on HN