Interfaces – The Most Important Software Engineering Concept • Hacker News Board

Re: Interfaces – The Most Important Software Engineering Concept

#41

Post by bunderbunder » Sat, Feb 27, 2016, 6:41 PM UTC

platz wrote: post #38

bunderbunder wrote: post #36

Earlier quoted context omitted.

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

Maybe, but I'm inclined to guess that it could probably be made workable without much more pain than what it takes to interact with F#'s curried functions from C#.

Usually the recommended approach for making F# code usable from C# is to add an object-oriented wrapper layer to the F# library. That ends up being much, much easier in practice than trying to deal with F# code on its own terms from C#.

Re: Interfaces – The Most Important Software Engineering Concept

#42

Post by chriswarbo » Sat, Feb 27, 2016, 7:01 PM UTC

naasking wrote: post #15

EvanPlaice wrote: post #4

Awesome write up. While I agree that dynamically typed languages -- by their loosely defined API requirements -- are more difficult to scale, it's not difficult to add type checking and/or provide a well structured public API where necessary. I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increa…

> I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increased surface area for potential bugs, and overly restrictive limits that require 'creative' workarounds to effectively write code. Given this description of statically typed languages, I'm guessing you haven't tried OCaml or Haskell.

Whilst I've found Hindley-Milner systems much nicer to use than, e.g. Java, they can still require boilerplate and "creative" workaround which wouldn't be necessary in dynamically typed languages.

For example, I've recently been struggling with a Haskell library that makes heavy use of `TypeRep` values, which is fine when everything's done in a single process invocation, but very awkward when attempting to serialise/deserialise (e.g. to pass data between processes, or to suspend a computation and resume it later)

Re: Interfaces – The Most Important Software Engineering Concept

#43

Post by MiaoYu_Goh » Sun, Feb 28, 2016, 6:10 PM UTC

bunderbunder wrote: post #41

platz wrote: post #38

Earlier quoted context omitted.

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

Maybe, but I'm inclined to guess that it could probably be made workable without much more pain than what it takes to interact with F#'s curried functions from C#. Usually the recommended approach for making F# code usable from C# is to add an object-oriented wrapper layer to the F# library. That ends up being much, much easier in practice than trying to deal with F# code on its own terms from C#.

"... add an object-oriented wrapper layer to the F# library."

Do you have any sample code that serves as an example? It would be immensely helpful. Thanks.